Session Tracking

One of the confusing aspects of web applications to some is the understanding of session tracking. Session tracking is just that, tracking sessions. When a communication channel (request and response) has been established between the client (or browser) and the server, a record needs to exist tracking the conversation. HTTP is a stateless protocol, meaning it does not maintain the status of the communication string or source of the communication. For example, if you were to go online to perform Christmas shopping, and you continuously purchase items by adding it to the application’s shopping cart, the server should know which client the request is coming from and add it to the correct cart.

There are three popular methods to the stateless protocol.
1. Cookies
2. URL encoding
3. Hidden form fields

The three methods serve as a way for the server to identify individual request and track sessions.

Fixing HTTPOnly and Secure Cookie Flags

I read a great entry from the ModSecurity blog. This is in relation to repairing the HTTPOnly and Secure Cookie flags. According to the Microsoft Developer Network, HttpOnly is an additional flag included in a Set-Cookie HTTP response header. Using the HttpOnly flag when generating a cookie helps mitigate the risk of client side script accessing the protected cookie (if the browser supports it).

According to the OWASP website, if the HttpOnly flag (optional) is included in the HTTP response header, the cookie cannot be accessed through client side script (again if the browser supports this flag). As a result, even if a cross-site scripting (XSS) flaw exists, and a user accidentally accesses a link that exploits this flaw, the browser (primarily Internet Explorer) will not reveal the cookie to a third party.

If a browser does not support HttpOnly and a website attempts to set an HttpOnly cookie, the HttpOnly flag will be ignored by the browser, thus creating a traditional, script accessible cookie. As a result, the cookie (typically your session cookie) becomes vulnerable to theft of modification by malicious script.
If you are only interested in addressing the missing "Secure" cookie flag, then you can simply take the example from the previous post and edit it slightly to swap out "httponly" with "secure". If, however, you want to try and address both of these issues together, then you will need to change the rule set approach a bit so that it works correctly. This is because there are now three different scenarios you have to account for -

• Missing HTTPOnly flag
• Missing Secure flag (if the SessionID is being sent over an SSL connection)
• Missing both HTTPOnly and Secure flags

With this in mind, here is an updated rule set that will handle both missing HTTPOnly and Secure cooking flags.

#
# First we want to capture Set-Cookie SessionID data for later inspection
SecRule RESPONSE_HEADERS:/Set-Cookie2?/ "(?i:(j?sessionid|(php)?sessid|(asp|jserv|jw)?session[-_]?(id)?|cf(id|token)|sid))" "phase:3,t:none,pass,nolog,setvar:tx.sessionid=%{matched_var}"

#
# We now check the saved SessionID data for the HTTPOnly flag and set an Apache
# ENV variable if it is missing.
SecRule TX:SESSIONID "!(?i:\;? ?httponly;?)" "phase:3,t:none,setenv:httponly_cookie=%{matched_var},pass,log,auditlog,msg:'AppDefect: Missing HttpOnly Cookie Flag.'"

#
# Next we check the saved SessionID data for the Secure flag (if this is an SSL session)
# and set an Apache ENV variable if it is missing.
SecRule SERVER_PORT "@streq 443" "chain,phase:3,t:none,pass,log,auditlog,msg:'AppDefect: Missing Secure Cookie Flag.'"
SecRule TX:SESSIONID "!(?i:\;? ?secure;?)" "t:none,setenv:secure_cookie=%{matched_var}"

#
# The final check is to see if BOTH of the HTTPOnly and Secure cookie flags are missing
# and set an Apache ENV variable if they are missing.
SecRule TX:SESSIONID "!(?i:\;? ?httponly;?)" "chain,phase:3,t:none,pass,log,auditlog,msg:'AppDefect: Missing HttpOnly and Secure Cookie Flag.'"
SecRule SERVER_PORT "@streq 443" "chain,t:none"
SecRule TX:SESSIONID "!(?i:\;? ?secure;?)" "t:none,setenv:secure_httponly_cookie=%{matched_var}"

#
# This last section executes the Apache Header command to
# add the appropriate Cookie flags
Header set Set-Cookie "%{httponly_cookie}e; HTTPOnly" env=httponly_cookie
Header set Set-Cookie "%{secure_cookie}e; Secure" env=secure_cookie
Header set Set-Cookie "%{secure_httponly_cookie}e; Secure; HTTPOnly" env=secure_httponly_cookie

These rules will both alert and fix these cookie issues. You may want to switch the actions to "nolog" so that you are not flooded with alerts.

URL Encoding

URL encoding is the process of converting strings into valid URL format that can be transmitted over the Internet. URLs can only be sent over the Internet using ASCII based character sets. Since URLs often contain characters outside the ASCII set, the URL has to be converted into a valid ASCII format.

URL encoding is normally performed to convert data passed via html forms, because such data may contain special character, such as "/", ".", "#", and so on, which could either: a) have special meanings; or b) is not a valid character for an URL; or c) could be altered during transfer. For instance, the "#" character needs to be encoded because it has a special meaning of that of an html anchor. The character also needs to be encoded because is not allowed on a valid URL format. Also, some characters, such as "~" might not transport properly across the internet.

Encoding techniques can be use to avoid pattern detection when performing web application testing, especially SQL injections. Encoding has the effect of completely changing the text much in the same way cryptography changes the text it is meant to hide from unintended viewers.

Application Secuirty Testing

Websites
http://phpsec.org/projects/guide/4.html - PHP Security Guide
http://www.rfidblog.org.uk/hancke-rfidrelay.pdf
http://en.wikipedia.org/wiki/Session_fixation - Session Fixation
https://addons.mozilla.org/en-US/firefox/addon/573 - Firefox cookie editor
http://www.criticalsecurity.net/ - Forum