GWAPT Certification!
Recently I achieved getting my GIAC Web Application Penetration Tester (GWAPT) certification. I passed with a 96% and I highly recommend anyone considering going into web application pentesting to take. I took a SANS course with Kevin Johnson and had a great experience.Ok, so let's get to today's post.
Basic Security Tenets for protecting web applications
I'm going to attempt to consolidate the many attacks we see against web applications and some steps you can take to prevent them in your web applications. Again, these are some basic things coming off the top of my head and is by no means a comprehensive list.Client Side Code:
With AJAXified (is that actually a word now?!?) websites, more and more logic is being passed down to the client. This presents a problem (or an opportunity if you're someone like me) as anything being passed down to the client can be modified and used.
Seriously avoid putting things like input validation and authentication logic on the client side as it makes the bad guy's job much much easier. Remember that anything on the client can (and will) be turned against you.
Session Handling:
One of the ways attackers go after web applications is attacking the session management system itself. If an attack is able to get a legitimate session, they've essentially unlocked a door and allowing them to continue through your application. Here are some things you can do to help eliminate session vulnerabilities.
- Don't build your own session management piece, use a framework
Most web languages have a method for handling sessions built into them and are more likely to be updated if a vulnerability is found. I would discourage anyone who is trying to build their own session management from scratch. This problem is largely fixed if you use what's already provided.
- Prevent Session Fixation, most notably in Microsoft ASP.net
Most web languages have a method for handling sessions built into them and are more likely to be updated if a vulnerability is found. I would discourage anyone who is trying to build their own session management from scratch. This problem is largely fixed if you use what's already provided.
Session Fixation occurs when an attacker is able to get a session ID before authenticating that does not change after authenticating. This is pretty easy to check as all you need to do is look at your session ID before authenticating and after. If it changed then congratulations you don't have a problem with session fixation.
Microsoft's ASP.net still has a problem with session fixation; so if you use ASP.net make sure your site is not vulnerable. If you find that you do need to patch this up, OWASP has a page explaining one tactic to do so here
Most web languages have a method for handling sessions built into them and are more likely to be updated if a vulnerability is found. I would discourage anyone who is trying to build their own session management from scratch. This problem is largely fixed if you use what's already provided.
Most web languages have a method for handling sessions built into them and are more likely to be updated if a vulnerability is found. I would discourage anyone who is trying to build their own session management from scratch. This problem is largely fixed if you use what's already provided.
Session Fixation occurs when an attacker is able to get a session ID before authenticating that does not change after authenticating. This is pretty easy to check as all you need to do is look at your session ID before authenticating and after. If it changed then congratulations you don't have a problem with session fixation.
Microsoft's ASP.net still has a problem with session fixation; so if you use ASP.net make sure your site is not vulnerable. If you find that you do need to patch this up, OWASP has a page explaining one tactic to do so here
XSS Prevention:
Cross Site Scripting is a very common attack method and nearly every input on a page can be a potential attack vector. Successful XSS attacks can allow attackers to deface websites, hijack sessions by stealing cookies, or even redirect users to malicious websites.
- Input Validation
Articles talking about XSS are abundant on the web so I won't go into tons of detail here (if you want more detail please ask, there's enough material there to be its own post). Suffice it to say that whenever you're accepting input, make sure that you're only allowing the kinds of information in that field that it needs. Phone numbers only need numbers and either dashes or sometimes periods. I can't think of a good reason to allow alpha characters and <> inside of a phone number field. Basically just think of what the user would actually need and restrict the characters they can input to only what they require. If at all possible, utilize white listing instead of black listing. Black listing is only effective if you've covered every possible BAD entry, and since attacks are always evolving, this can be a risky gambit.
Another measure to implement on input validation is to use canonicalization which can prevent double and triple encoded attacks. Canonicalization reduces input to their most basic form before being accepted as input.
This might seem like a lot of work (and it really can be), but this is the best way for web applications to prevent XSS attacks.
- Output Encoding
Even if we're filtering our input, what if we missed something? Most developers use black lists instead of white lists because it's harder to list all of the valid inputs you can put in vs a list of obvious attacks. Encoding outputs can prevent attacks removing the malicious entries and thus defanging the attack. This is especially important if dangerous characters have to be used as inputs.
- Forums should use non-HTML tags for formatting
This obviously only applies to Forums, but changing the formatting tags to non-html entities prevents attacks where these tags can be used for stored XSS attacks. A browser is never going to misinterpret [:bold:] as <b> for example. This gives the developer the freedom to disallow html tags inside their forum posts (or at least escape everything as data) to prevent the attack.
Articles talking about XSS are abundant on the web so I won't go into tons of detail here (if you want more detail please ask, there's enough material there to be its own post). Suffice it to say that whenever you're accepting input, make sure that you're only allowing the kinds of information in that field that it needs. Phone numbers only need numbers and either dashes or sometimes periods. I can't think of a good reason to allow alpha characters and <> inside of a phone number field. Basically just think of what the user would actually need and restrict the characters they can input to only what they require. If at all possible, utilize white listing instead of black listing. Black listing is only effective if you've covered every possible BAD entry, and since attacks are always evolving, this can be a risky gambit.
Another measure to implement on input validation is to use canonicalization which can prevent double and triple encoded attacks. Canonicalization reduces input to their most basic form before being accepted as input.
This might seem like a lot of work (and it really can be), but this is the best way for web applications to prevent XSS attacks.
Even if we're filtering our input, what if we missed something? Most developers use black lists instead of white lists because it's harder to list all of the valid inputs you can put in vs a list of obvious attacks. Encoding outputs can prevent attacks removing the malicious entries and thus defanging the attack. This is especially important if dangerous characters have to be used as inputs.
This obviously only applies to Forums, but changing the formatting tags to non-html entities prevents attacks where these tags can be used for stored XSS attacks. A browser is never going to misinterpret [:bold:] as <b> for example. This gives the developer the freedom to disallow html tags inside their forum posts (or at least escape everything as data) to prevent the attack.
No comments:
Post a Comment