Turbine has had the functionality to detect a resubmitted form using a similar technique. A session access counter is updated in the session every hit. In a "sensible" form the value of this counter is placed as hidden field. Then the value of the form parameter is checked against the current value session counter. Since in Turbine the session counter is updated prior to this check, it makes sure the session counter is one greater than the form value. Maybe we should switch to using a random key. The session access counter was something that was already being updated when we were searching for a solution to the back button problem. But a number that is likely between 1 and 50 is probably not random enough. I would like to see some more on this specific solution to the redirect security hole. Anyone with some quick links? John McNally > -----Original Message----- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > Sent: Friday, December 15, 2000 8:58 PM > To: [EMAIL PROTECTED] > Subject: Re: Struts and Web Application Safety > > I had started down a similar path, although not for security reasons, so > that you > could reliably detect when a user tried to submit the same form twice > (because they > used the back arrow). I'd like to see what you have in mind -- we might be > able to > kill two birds with one stone. > > Craig > > Didier Girard wrote: > > > Hello, > > > > I'm working on a patch for the redirect security hole. > > You can find more information on this hole here : > > http://lwn.net/2000/features/Redirect.phtml > > > > With this hole it is possible to redirect you to a page > > which performs some actions on a site where you have already > > authenticated yourself. > > > > In order to protect "sensible" forms on a site, > > the best way is to > > put a random key in the HttpSession and in the sensible form. > > When the form is submitted, if the keys in the > > request and in the HttpSession are the same, > > it is pretty sure that the redirect hole has not been exploited. > > > > I have already coded a solution for Struts, can we discuss > > it ? > > > > didier > > > > "Craig R. McClanahan" wrote: > > > > > > Hello Struts Developers and Users, > > > > > > As Struts becomes ever more popular (look for additional discussion of > Struts in > > > various articles and book chapters in the next few months), one of our > > > responsibilities as framework designers is to make sure we > encourage/require > > > "safe programming" practices, whenever that goal is feasible. I was > inspired to > > > write this message by reading on Linux Weekly News <http://lwn.net> this > week > > > about a vulnerability in the Charles Schwab online trading system. > > > > > > The problem is generally known in security circles as a "cross-site > scripting" > > > vulnerability. There was even a CERT advisory on this issue last > February: > > > > > > http://www.cert.org/advisories/CA-2000-02.html > > > > > > The sad point of the LWN coverage is that this problem is not a new one, > and is > > > by no means restricted to Charles Schwab. In the same industry, E*Trade > has > > > also suffered from a very similar problem. There are undoubtedly many > other > > > applications that are vulnerable. And it's all the application > developer's > > > fault. > > > > > > The key vulnerability that causes the problem here is accepting text, > say in a > > > <form:textarea> tag, and displaying it back to the user as HTML text > without > > > filtering out HTML tags. Anyone who has used a naively-written > guestbook app, > > > for example, has probably suffered from a user entering text like this > in their > > > message: > > > > > > <a href="http://www.my-favorite-x-rated-site.com">Cool Pictures</a> > > > > > > which, if you don't take appropriate measures when you render your page, > could > > > generate a real hyperlink to a site you would normally never willingly > link to. > > > > > > Now imagine, instead of an embarrassing link to a site like this, the > crafty > > > guestbook user entered JavaScript code that sent everything the client > browser > > > knows about the user to some hacker's site. At best, such information > could be > > > used to make it look like a particular user is accessing inappropriate > sites. > > > At worst, such code could be used to hijack the user's session and > execute > > > unauthorized transactions on an online brokerage system -- as both > Schwab and > > > others have discovered. > > > > > > What does this have to do with Struts? Well, we have the opportunity to > protect > > > application developers from some consequences like this, if they are > using the > > > Struts custom tags to render their output. For example, with the > <bean:write> > > > tag, you can ask for the output to be filtered for characters that are > important > > > in HTML and XML (such as the "<" character that opens a tag). If you > carefully > > > do this on all input received from the user, you dramatically reduce the > risk > > > that your application can be subject to the particular attack described > in this > > > CERT Advisory. > > > > > > Right now, though, the <bean:write> tag defaults to filtering only when > you ask > > > for it. I'd like to propose that we change the default to "true", so > that > > > output is filtered unless you explicitly ask for it *not* to be. > > > > > > In addition, I'd ask for your help in identifying places where Struts > can help > > > developers create *safe* applications, not just *functional* ones. Are > there > > > other areas where you see vulnerabilities in Struts-based applications, > where > > > the framework can assist in improving the security of an application > based on > > > it? > > > > > > Craig McClanahan ------------------------------------------------------------ To subscribe: [EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/> Problems?: [EMAIL PROTECTED]
