SEO Blog

Its amazing to me what tactics black hats will use for the sake of SEO. Some, illegal by US & international law. Some Blackhats will go much further than just doing the plain, old type of gaming Google listed in the earlier post, they will turn to computer crime. I would like to take a minute and actually get on the topic that I love, computer security & how you can prevent your blog/web page from getting hacked via XSS.

When you hear blackhat SEO uses such methods like XSS(Cross Site Scripting), which, isn’t hard to perform,but, easily mitigated (Sorry, their is no bullet proof methodology that is a cure all). The main goal more often than not is to steal credentials, i.e. User name, Password & maybe just spam a blog or even get credit card information, perform redirects to different sites, bombard refer logs, etc. Lets get started with identify weak spots(attack vectors).

So, you have a nice little blog, you allow users to post comments on your blog. Allowing users to input ANYTHING is more often than not, a bad idea. Yes, a lot of blogs take care of some of these issues I raise, however, it would behoove you to check your blog yourself. Yeah, no one likes to hear that & the knee jerk reaction is just to ignore this and go about business as usually. But, do you want your blog/web page to be a launching point for spywear, adware junk, browser hijacking, leading to identity theft? By allowing users to post things even as simple as html images, you have opened a can of worms.

“<input type = “image” dynsrc = “javascript:[malicious code]”>”

“<a href=javascript:alert([malicious code])>” opps. what if they just do something like, user connection timeout, please log back in, with a nice prompt box to do such.. Thus, having code to redirect that input to another server where all that information will be stored and used for later use.. Remember, users more often than not use the same handle, use the same password across many domains.. Thus, I’m trying to educate people on using different passwords and logins for each site they visit.

Their are different vectors of attacks, type0, type1,type2.. lets get to type one. Type one attacks utilize local scripting. Alot, of times web servers will put local scripts onto a clients machine, associate things like Session IDs and the like. Well, if I could get malicious code onto a local machine, then, have it triggered by some event later on in the page. It could leverage the attacker the ability to run code on the victims machine, maybe even at an elevated set of privileges, allowing for a further a future compromise or just put spywear and junk on the PC.

Lets, examine type1. This one can be as simple as a simple joke or something that can look legitimate enough to destroy a reputation of a business. Type1 XSS attacks utilize dynamic generated pages. And are not encoding your webpages. Lets say for example you do something stupid with one of your generated pages like:

http://www.example.com/error?An%20Error%20Has%20Occured.htm

Then, that message is then displayed on your page. Well, do you think if the error call will display that “An Error Has Occurred” then some generic page to log in or sign up.. Do you think you could probably write anything in url after error? and have it pop up, lead into a TYPE0, TYPE2 attack? I think so… Can you midegate this to some degree, yes. Better yet think of a different way of handling errors, altogether.

So, is it all pretty bleak? Yes. Can you do alot to lower your risk factors.. Absolutely! Are these by any means bullet proof, no.

• Encode all posts or user inputed data. You’ll have to sanitize user input, by disabling users the ability to put HTML tags & Javascript on pages, this is called escaping. Javascript escape()
• Parse all HTML data as to make sure code being put onto the page meets what is referred to as a whitelist or use in conjunction with a black list(code that is absolutely not allowed to appear). You can run into problems with this because your really dealing with a wide range of approaches to get an attack through. These types of lists can grow very large.
• HTTP only cookie option.
• Associate any session cookies through IP address only, if you are accessing a page behind a NAT, you will only have to worry about others behind that NAT.

I do just want to make one minor note about black hat SEO companies that employ these type of methods. They people they employ to do such things are nothing more than script kiddies, with no actual hacking skill. Its not like they actually do any vulnerability research, they are too incompetent to do such. They know nothing of reverse engineering, nor, assembly language, fuzzing techniques.. None of this, its because they are bad at what they do, they do a poor job at hacking, nor, does any security professional consider vandalizing a page a true hack. They wait for the big boys, who actually spend hours of the days actually looking deep into source code in white box testing, they employ gray box testing with using fault injection & some source code, and have no problem moving towards actual black box testing of any given application. To be blunt they can actually read code, the closest thing they get to a zero day vulnerability is reading BugTraq for a vulnerability that has yet to be patched, but, they haven’t done a thing. IF webmasters & users alike apply common sense security, keep up with what can be done to mitigate attacks they would lower their chances of becoming victims of such attacks. If only because they have made it harder than the next guy.

If I get a positive result from this post.. I’ll get more exact with the mitigation techniques. Until then, use your friend Google on how to midegate these threats. Remember, we just don’t do SEO & SEM here at Graphic SEO, we also do secure & robust web development. I would like to see every company take a comprehensive examination of their applications in deployment & under development. Webmasters too. Everyone, can benefit through enhanced security & help keep those blackhats away.

This entry was posted on Wednesday, May 28th, 2008 at 10:59 am and is filed under Security. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.