|
|
Dec
1
Posted by:
cathal connolly
Thursday, December 01, 2005 5:00:00 AM
A common security problem for web applications is cross-site scripting (XSS). Cross-site scripting attacks are usually created when some user input is rendered as part of the output of a page. In DotNetNuke we have a number of core functions which are used to help detect and protect against XSS attacks, but due to the large number of different browsers, with different exploits and the ability to encode and disguise an XSS attack, it's difficult to protect against all of them (a recent survey recorded 90+ variants). At some later point, I'll blog about some of the core methods, and where and when they're approriate to use in your own modules, but today I just wanted to mention another layer of protection against XSS that we added in 3.2/4.0.
As DotNetNuke is a framework, we're always looking for opportunities to add capabilities that all users can avail of without having to modify their setups. With 3.2/4.0 we added framework support for HttpOnly cookies.
From Internet Explorer 6 SP1, Microsoft added an attribute to cookies, called http-only. When a cookie that has this attribute is accessed from client script (e.g. javascript added in an XSS attack), Internet Explorer will return an empty string, rather than the contents of the cookie. As the majority of XSS attacks centre on stealing information from a cookie, or stealing the cookie itself to try to impersonate someones identity, this removes the hackers ability to steal the desired payload. HttpOnly doesn't affect the normal operation of the cookie, which still gets passed back and forth from the originating server as normal.
Sadly, at the minute only IE6 SP1 and above support this, which means it's only effective for approximately 50-90% of users . Firefox/Mozilla has it listed as an enhancement for a couple of years now, but haven't a solution yet, though it's looking more promising recently.
In asp.net 1.1 there was no easy way to add the attribute to cookies, so we've added code to one of the httpmodules (DNNMembershipModule) to append the attrbiute if necessary to any cookies. At the time the code was written, Microsoft had indicated that they were going to default the value to True for all cookies in asp.net 2.0, so I added code to ignore 2.0 (and above) versions of the framework. Unfortunately, Microsoft decided to default it to false for the final release and didn't list that fact on any of the breaking changes documents I saw, meaning that the attribute is missing in the current version of 4.0.
If you're running 3.2 (under asp.net 2.0) or 4.0, then you can manually add it by adding < httpCookies httpOnlyCookies="true" requireSSL="false" domain="" /> into the system.web element of your web.config. This change has already been added to the next release.
5 comment(s) so far...
Re: Reducing the effectiveness of cross site scripting attacks
Hi... Not related to your article, but I thought I would see if you have any thoughts re to my question here: http://forums.asp.net/1130256/ShowPost.aspx
Also wondering what (if any) changes are needed in DNN to support SSL.
Thanks!
By jyjohnson on
Saturday, December 03, 2005 10:39:41 PM
|
Re: Reducing the effectiveness of cross site scripting attacks
Interesting idea on protection of the cookies from attack, but the methodology has one serious flaw. Since each Cookie is seperate in function, and all the DNN (Core) cookies are used and abused only by the Server - the DNN (Core) will continue to function without error. However, there are a variety of modules available commercially which utilize the Cookie on both the Server, and Client. Now with the advent of the change in the core - when communication occurs that Javascript must be capable of utilizing - the Modules are useless - because the Cookie is not available - even though the actual Cookie is in fact a Module Cookie, not a Core cookie. Why is DNN protecting ALL cookies - instead of just its own?
With that said, at what point will the core provide a workaround to allow the Core to work properly with modules that need cookies for both the Server and the Client side operations? Can this be done at atleast at a Configuration level?
Thanks in advance -
Kevin M. Schreiner
By kevinmschreiner on
Wednesday, December 21, 2005 10:42:45 PM
|
Re: Reducing the effectiveness of cross site scripting attacks
In order to make the cookie protection a bit more selective, and to provide flexibility for module developers while protecting the cookies that DNN uses for security purposes - I modify the HttpModule.DNNMembership library, extending the OnEndRequest event function to read:
'--------START CODE SNIPPET--------'
Public Sub OnEndRequest(ByVal s As Object, ByVal e As EventArgs)
Dim Context As HttpContext = CType(s, HttpApplication).Context
Dim Response As HttpResponse = Context.Response
'avoid adding to .net 2 as httpOnlyCookies default to true in 2.0
If System.Environment.Version.Major < 2 Then
Const HTTPONLYSTRING As String = ";HttpOnly"
For Each cookie As String In Response.Cookies
Dim path As String = Response.Cookies(cookie).Path
Dim name As String = cookie.ToUpper
Select Case name
Case ".ASPXANONYMOUS", "ASP.NET_SESSIONID", "LANGUAGE",
".DOTNETNUKE", "PORTALALIASID", "PORTALROLES"
If path.EndsWith(HTTPONLYSTRING) = False Then
'append HttpOnly to cookie
Response.Cookies(cookie).Path += HTTPONLYSTRING
End If
End Select
Next
End If
End Sub
'--------END CODE SNIPPET--------'
This works splendidly for 3.2, but I haven't checked the version changes between 3.2 and 3.2.1. I'm not certain this covers all the DNN secure cookie name/value pairs, but it should provide more specific coverage of the cookies that truly require security and those that do not.
Thanks -
Kevin M. Schreiner
By kevinmschreiner on
Thursday, December 22, 2005 2:13:23 PM
|
Re: Reducing the effectiveness of cross site scripting attacks
Kevin,
i'm working on something similar at the moment, but theres the added complication of asp.net 2.0 where httponly is set at the web.config level. We may have to alter the 4.x code to apply the value for each cookie in turn, but at the minute we're trying to minimise the amount of difference between the 2 DotNetNuke versions, as it's a large overhead keeping them in sync. I'll be working through the use cases over the holidays, to try and find an optimal solution.
By cathal on
Thursday, December 22, 2005 2:33:25 PM
|
Re: Reducing the effectiveness of cross site scripting attacks
Thanks Cathal,
For my own purposes, it only will directly affect users of one of my modules, which utilize 2 cookie settings for indirect communication between a server component and the client side javascript, similar in fashion to the AJAX model, but instead communication values occur within the cookies. I will be revising the model for the next release - so as to work with the current version of DotNetNuke. Hopefully there aren't too many developers who utilize similar technology - but the problem will become more apparent as AJAX becomes more utilized by other module developers. In most cases, protection of all the cookie values is beneficial, but unfortunatly - it only protects cookies in IE.
Keep up the good work, and Happy Nuking!
Kevin M Schreiner
By kevinmschreiner on
Friday, December 23, 2005 7:07:15 PM
|
|
|