CFTOKENaround in the URL. It is possible, therefore to copy somebody's URL into your own browser and steal their identity. Though session variables do time out after prolonged periods of inactivity (as designated by the server), there is a window of time where a hijacking could happen.Most developers use one of two different approaches:
HTTP_REFERERvariable for each page request and drop the session if the variable is empty.
HTTP_REFERERis a browser variable and could be hacked by anyone so inclined, AND, browsers such as Opera & iCap, etc actually give the user the ability to turn off the reporting of the
HTTP_REFERER. FINALLY, in some versions of Netscape, the sub-frames of a
FRAMESETdo not get issued the
HTTP_REFERERwhen they are requested (Oh yeah, I don't like Netscape® either).2 does not work for dynamic proxies. AOL, for example, routes its users through proxies, and the particular proxy used from page request to page request might be different. Since a proxy reports its own IP address to the server, you cannot use this method without excluding AOL users from using your site. Maybe it's time to come up with another method.
If only the US Government hadn't pressured Intel to remove the serial numbers from CPU's...
<cfapplication name="whatever" clientmanagement="No" sessionmanagement="Yes" setclientcookies="No" sessiontimeout="#CreateTimeSpan(0,2,0,0)#">And, it would be a good idea to have session timeout turned on, like it is set for 2 hours in the example above.The overall idea is that you want to set a cookie that contains their IP address and set a session variable that contains the same IP address. We are able to inspect the IP address of the request VIA the
cgi.remote_addrvariable. In some instances, this variable contains the actual IP of the source machine. In others, if a proxy is used, for example, this variable will contain the last most proxy used before the request hit the Internet.At the time of setting, all three variablesthe cookie, the session variable, and their actual IP addressshould match. So, in the future so long as their session variable IP address and the cookie IP address match, keeping in mind that we'll never send a cookie that contains anything other than their
<!--- Session Hijacking Defense --->Feedback is encouraged and welcomed for this article. Session hijacking is a long-standing problem and very few implementations of a hijacking defense system are bulletproof. If we put everybody's head together on this, we may find a solution yet.I would like to thank .jeff again for his help in creating this document.
<cfparam name="session.cookieset" default="0"><cfparam name="url.cftoken" default="0"><cfparam name="session.ipaddr" default="">
<!--- We assume cfid and cftoken at at the end ofthe query string and make a query string w/o them ---><cfset new_query = cgi.script_name & IIF(Len(cgi.query_string), DE("?#cgi.query_string#"), DE(""))><cfif FindNoCase("cfid=", new_query)> <cfset new_query = Left(new_query, FindNoCase("cfid=", new_query) - 2)></cfif>
<cfif Val(url.cftoken)><cfif IsDefined("cookie.ipaddr") AND LEN(session.ipaddr)> <cfif cookie.ipaddr NEQ session.ipaddr> <!--- session is being hijacked ---> <cflocation url="#new_query#" addtoken="No"> </cfif> <cfelse> <cfif session.cookieset> <!--- This is not the first time the tokens have appeared in the URL ---> <cfif session.ipaddr NEQ cgi.remote_addr> <!--- either hijacking or did not accept cookie. We need cookies in this case, so send to a page saying as such ---> <cflocation url="#new_query#" addtoken="No"> </cfif> <cfelse> <!--- This is the first time the tokens have appeared in the URL ---> <cfcookie name="ipaddr" value="#session.ipaddr#"> <cfset session.cookieset = 1>
<cfset session.ipaddr = cgi.remote_addr><html> <head> <meta http-equiv="Refresh" content="0"> </head> <body bgcolor="#dddddd"> </body> </html> <cfabort> </cfif> </cfif></cfif>
<!--- /Session Hijacking Defense --->