Miscellaneous Security

Reading time: 2 – 4 minutes

Photo: Mrs. Magic

When testing web applications, penetration testers should look at how the session is handled. Session management is commonly overlooked by developers and system administrators. It is so often overlooked that it is one of the OWASP Top 10, refereed to as “Broken Authentication and Session Management.”

This article will cover certain attributes that cookies typically have. In the future we will address how to use attribute tags to help aid developers in securing their applications. This article assumes the reader has a basic understanding of what a cookie is.

Here is a sample HTTP response. This is what the server responds with after a client request is made. The response has been edited for brevity.

HTTP/1.1 200 OK
Content-Type: text/html
Set-Cookie: session=YnJldHQ6bXlwYXNzd29yZA==;expires=Thu, 30 Dec 2037 00:00:00 GMT;path=/;domain=.misc-security.com
Content-Length: 8400

For those unfamiliar with cookies, a cookie consists of a name/value pair. In this case the cookie name is “session” and the cookie value is “YnJldHQ6bXlwYXNzd29yZA==”

Following the cookie name/value pair are the attribute/value pairs that apply to that cookie and are delimited with a semicolon. In this example their are three attribute/value pairs: expires, path, and domain.

Expires Attribute

expires=Thu, 30 Dec 2037 00:00:00 GMT

The expires attribute is used to tell the browser when the cookie should no longer be used. Browsers will cache this cookie locally until the expires date is reached. When the expires date is reached the browser will stop sending the cookie after the browser is closed. In our example the cookie will remain valid until December 30th, 2037.

Path Attribute

path=/

The Path attribute specifies the subset of URLs to which this cookie applies. In this case, the cookie will be sent for any request to this server. If a user requests /bobsapp/ or /tomsapp/ this cookie will be sent.

Domain Attribute

domain=.misc-security.com

The Domain attribute specifies the domain for which the cookie is valid. An explicitly specified domain must always start with a dot. In our example, this cookie will be sent to misc-security.com and any sub-domains of misc-security.com (e.g. asparagus.misc-security.com).

In a future article we will continue looking at the attribute/value pairs that cookies can have and will even revisit these attributes explaining how each needs to be understood to securely handle a user’s session.

Further Reading:

RFC 2109 – HTTP State Management Mechanism
RFC 2965 – HTTP State Management Mechanism (New Version)

Reading time: 2 – 3 minutes

Photo: Joe Penniston

This is the fifth-part in a ten-part-series describing the OWASP Top 10. (See all the OWASP Top 10)

What is Cross-Site Request Forgery (CSRF)

Cross-Site request forgery is a client-side vulnerability that allows an attacker to make requests on the user’s behalf. Although, most CSRF exploits require a user to be authenticated to the susceptible site to be successful, this is not always the case.

An Example of Cross-Site Request Forgery

A user (victim) opens their browser and logs on to their online banking application located at http://bank.com

After checking their balance they browse away from the site (without logging off) and start reading web pages about olives from Madagascar. One of these olive sites is owned by an attacker. The attacker’s website has the following img src tag:

<img src="http://bank.com/transfer.asp?to_acct=445544&amount=1000">

When the victim’s browser loads the malicious page that contains this img src tag, the victims browser makes the transfer request (/transfer.asp?to_acct=445544&amount=1000) to bank.com using the authenticated cookie from the earlier session. Upon making this request, the bank then transfers $1,000 from the victim’s account to account 445544. The attacker has now successfully executed a cross-site request forgery attack against a user of bank.com

How Do You Prevent Cross-Site Request Forgery

Any sensitive request that is generated by the user should force the user to “re-authenticate.” A simple example is that of change password functionality. You always want to verify the user knows the old password before changing their password, even if they are currently authenticated.

If you determine that “re-authentication” may be an inconvenience for the user or if all of your requests are considered sensitive then the application developers should include a random token that is unique to the user session. This token should not be present in the cookie, but rather as a hidden field in the HTML and then appended to the URL during any form submission.

When the attacker attempts to trick the users browser into making a request, the web application will look for this random token. The random token will not exist for the request, and the request will be denied. This prevents the CSRF attack from being successful.

Note: Having SSL does not protect your application from CSRF vulnerabilities.

Reading time: 2 – 2 minutes

When developing a security strategy for web applications many companies have no idea where to begin. The Open Web Application Security Project (OWASP) understood this problem and developed the OWASP Top 10.

The OWASP top 10 are the top 10 vulnerabilities that are found in web applications. If you have an hour or don’t want to read all of these posts, you can simply watch a video.

If you are a developer, you should understand these vulnerabilities. Understanding them is critical into introducing less vulnerabilities into your code.

The OWASP Top 10:
A1 – Cross Site Scripting (XSS)
A2 – Injection Flaws
A3 – Malicious File Execution
A4 – Insecure Direct Object Reference
A5 – Cross Site Request Forgery (CSRF)
A6 – Information Leakage and Improper Error Handling
A7 – Broken Authentication and Session Management
A8 – Insecure Cryptographic Storage
A9 – Insecure Communications
A10 – Failure to Restrict URL Access