|
Cross site Script hacking using the GET method |
||||||||
I've dealt with Cross Site scripting (XSS) attacks before ( http://www.mccran.co.uk/index.cfm/2009/4/6/Cross-Site-scripting-hack-test-form), so I'm familiar with the principles involved. In this example there is a subtle difference.
In the example above the vulnerability was created by POSTING a text string through the form action. In this example we will examine a similar vulnerability using GET. IE we will simply pass the attacking string through the url of the form, setting the form field value in the traditional 'url?variable=N' way.
To demonstrate this create a simple form:
2
3<form>
4
5<input type="text" name="formValue" size="20" value="<cfoutput>#attributes.formValue#</cfoutput>">
6<input type="submit" name="Action" value="Send">
7
8</form>
Call your form in a browser. Now append on the end of that url the text string below.
?attributes.formValue==>"><%2Ftitle><%2Fiframe><%2Fscript><%2Fform><%2Ftd><%2Ftr>
Reading through the string you'll notice that it is an Iframe constructor that is calling a url, in this case www.Google.com.
As the url is setting the value of 'attributes.formValue' this will be inserted into the form on the submit action. We are not posting it, so it will not be picked up by any custom POST action code.
One interesting point to mention here is that testing this in IE 8, it will actually be blocked by default, as it has detected that scripts are running over different domains.
So if you are in the habit of writing POST detection scripts, make sure you handle any other submissions as well!
|
An exploration of automated stress testing tools |
||||||||
Recently I was looking at the scalability of a web platform, and had to perform some stress analysis on it to evaluate whether or not it would accommodate the potential user base for a new application.
The idea was to pose the question:
"N percentage of web pages should load in X seconds, with no more than Z percent errors."
|
Basic fusebox fuseaction to handle security references |
||||||||
I am a big fan of fusebox, I like the way it handles inheritance, and I love the fact that it instinctively lends itself to a modular approach.
Part of the strength in using fusebox is in knowing exactly when each of the framework fuse actions run, and just what sort of functionality you can embed in them. In this case I'm using the "Pre fuse Action" to perform a basic security validation on any fuseactions in that circuit.
2 <cfargument name="myFusebox" />
3 <cfargument name="event" />
4
5
6 </cffunction>
Above is a blank prefuseaction, insert any code you want to perform on any of the other fuseactions in that circuit here. Note that it runs before the circuit action.
A basic session validation script could be something like:
2 <cfif NOT isdefined('session.loggedIn')>
3 <cfset session.logoutMsg = "Your session has timed out, please login again">
4 <cflocation url="index.cfm">
5
6 <cfif NOT isdefined('session.superadmin')>
7 <cfset session.logoutMsg = "You do not have sufficient rights to view Super admin functions">
8 <cflocation url="index.cfm">
9 </cfif>
10
11 </cfif>
In the code above I am checking for a valid session variables, and if it is not there sets an error message and redirects to the homepage.
This is a pretty basic "catch all - are you logged in?" type query, but if you have an administration circuit then it provides good basic fuseaction protection. I've extended it out one step further by creating a cfc call to this code which just returns true/false. Something like this:
I am currently extending this further with more robust security, and user roles and groups.
|
Coldfusion dropping session ID in fusebox application |
||||||||
I recently rolled out beta version of a new application I've been writing, only to discover that there was a bizarre session problem that didn't exist in dev, but does in live.
I've worked it out, but I thought I'd explore it some more. It is a fusebox 5.5 non xml application. The error I had was that as soon as I made a call through a "new" circuit, IE one I hadn't called before ColdFusion would generate a new session ID, and thus invalidate my current active session.
Looking through my application CFC I had this line of code present.
Setting this to true fixed the issue. This is because ColdFusion relies on the CFID and CFTOKEN to maintain the session state. You can either pass these two variables through the URL on every page request, which is a bit messy, or you can use a cookie. It is the variable above that lets the application use cookies on the user's session.
The problem with setClientCookies is that it is persistent, IE it is built for that session, and left on the user's pc, even after the session has expired, or they have left the application. Also some users will accept per-session cookies, but not persistent session cookies.
They are a lot more secure as per-session cookies, as they cannot be duplicated and hacked to spoof a previous user's session, and if you pass the token through the URL it is easy changed.
You could put something like this in your onRequestend function in application.cfc
2IsDefined("Cookie.CFTOKEN")>
3<cfset cfid_local = Cookie.CFID>
4<cfset cftoken_local = Cookie.CFTOKEN>
5<cfcookie name="CFID" value="#cfid_local#">
6<cfcookie name="CFTOKEN" value="#cftoken_local#">
7</cfif>
This will make them per-session. I originally thought that it was something to do with the Fusebox framework, but I had overlooked the simple fact that it was still a new page request, so would be lost. Although this doesn't explain why I wasn't getting this error in my development environment but did in live.
