The recent Chinese attacks against various US websites as well as the security breach at Facebook and Apple has put hacking and security back in the spotlight.
While these attacks were quite focused and sophisticated, the simple fact remains that the majority of attacks target simple holes in website architecture that can be proactively closed by developers and server admins making your website safer.
Hollywood likes to make hacking look easy and instant, but this isn’t always the case.
At the end of the day an attack usually results from a series of miniature fact-finding pokes that can tell the attacker what they are dealing with. There use to be a time that this sort of information gathering required dedicated tools like Fiddler, WireShark, or NetStumbler.
Today this isn’t necessarily the case since modern web-browsers include a lot of built in developer tools meant for good, but can be used to find out enough information to attack.
For example, starting at a target’s website the first thing an attack may do is to look at the additional information the server is freely telling them. Here they find out that they are dealing with an ASP.net site, running version 2.0.50727 on IIS 6.
That may not seem like much, but it instantly focuses efforts on exploits in Microsoft technologies as opposed to blindly attacking the site with techniques that don’t apply to that environment. A quick Google search reveals this further information:
“Microsoft ASP .NET Framework 2.0.50727.42 does not properly handle comment (/* */) enclosures, which allows remote attackers to bypass request filtering and conduct cross-site scripting (XSS) attacks, or cause a denial of service, as demonstrated via an xss:expression STYLE attribute in a closing XSS HTML tag. “
How do you protect yourself from this sort of fact finding?
It’s really a very simple solution; configure the server and application to not send this information. There may be unavoidable clues like file extensions for your website, but at least that isn’t delivering exact version information to a curious set of eyes.
Another easy form of attack simply involve URL manipulation. On a website that may be presenting small thumbnails of images for purchase; an attacker would able to use the same developer tools to spot a request like the one below.
Wanting to get the image without purchase, he may notice the “width=70” in the URL. What happens if he makes that “width=200”? He then discovers that the website has given a version of the image that is 200 pixels wide. What happens if “width” is removed? It serves back the full sized image, ready for download. If he puts a little more work into putting all of those URLs into a list, the attacker would then be able to use a small program that goes through that list requesting each image 1×1 — free of charge.
How do you protect yourself from this?
The best thing to do is to have your developer validate ALL input and set default values in the programming for values that may be missing.
SQL injection attacks take place on websites that simply take the input from the user and apply it to the programming with no validation applied. In the case of the missing width, this developer should have set a width himself if one was not present to always return back a smaller version of the picture.
At the end of the day if someone really wants to affect your website they will. But taking a few relativity easy proactive steps will not affect your true user and will make that attacker have to work quite a bit longer to get in.
Have you ever been the victim of hackers? How did you recover and what do you put in place as protection against future attacks?