<snip> I could look at weaving the code for the struts transaction token into my JSP. It's already so ugly, it won't make much difference to the aesthetics of the page. </snip>
Could be worth a go as it looks like you might have to serve up something to be submitted back as proof of valid browsing anyway, and the struts tokens should already have most of the server side token id generation and checking stuff done so its just a case of rendering it as a field or in the post url. That said Ive not really used them (tokens) myself so I could be barking up the wrong tree but they do sound similar to what your thinking of... -----Original Message----- From: Adam Hardy [mailto:[EMAIL PROTECTED] Sent: Wednesday, 14 April 2004 04:35 To: Struts Users Mailing List Subject: Re: [slightly OT] defensive strategy Could do, could do. However the voting form doesn't appear on any of my HTML pages - it appears as snippets in other people's HTML on external 3rd party websites, courtesy of <script> links to my JSP which serves up a whole bunch of javascript document.write() commands that tell the browser what HTML to construct when the page loads. I could look at weaving the code for the struts transaction token into my JSP. It's already so ugly, it won't make much difference to the aesthetics of the page. (I'm just lucky there's no code review on this) ta Adam On 04/13/2004 06:03 PM Andrew Hill wrote: > This rather leads me to think of the struts token support. Take a look at > the docs on it. It might be just the ticket. Basically you can setup a token > value that the html will cause to be submitted with the form, and the action > will check for this and reject the post if it doesnt have a valid token. > Mainly used to deal with double submits and such like. > > > -----Original Message----- > From: Adam Hardy [mailto:[EMAIL PROTECTED] > Sent: Tuesday, 13 April 2004 19:35 > To: Struts Users Mailing List > Subject: Re: [slightly OT] defensive strategy > > > On 04/13/2004 12:39 PM McCormack, Chris wrote: > >>Interesting problem. You could implement image tickets, ie for every >> user that wants to submit a form you generate a random sequence of >>characters as an obscured image. > > > That's not in the spec, thankfully! I'm only trying to put off the > semi-determined attacks and any security should be transparent. > > On 04/13/2004 12:38 PM Daniel Perry wrote: > >>There are lots of ways to counter this. The simplest is a combination >> of session + cookie. Most people wont know how to / have any desire >> to delete the cookie. > > > Problem with scripted attacks is that they drop the cookies and session > ids. > > > >>IPs are useful, but be careful: - Some of the big ISPs (eg freeserve >> in the uk) have 'hidden' proxy servers, so if popular you may get >>more than one vote per hour from the same ip legitimately. - NAT - >>more that one person on a private NATed network may vote in close >>proximity! > > > Rats! I knew there would be some problem with it. I don't want to block > any legitimate voters. > > > Actually I think I may have a solution now, to exclude scripted votes - > I shall just put a flag in the session to show that the user has > actually called up the HTML to see the vote. > > That way, any script which fires a submit at the voting system will be > rejected since it didn't first instantiate a session. > > Thanks for the ideas. Certainly helped my thinking. > > Regards > Adam > > > > > > >>-----Original Message----- From: Adam Hardy >>[mailto:[EMAIL PROTECTED] Sent: 13 April 2004 11:23 >>To: Struts Users Mailing List Subject: [slightly OT] defensive >>strategy >> >> >>Sorry for posting this OT question but I've got an issue that people >> on this list are very likely to have tackled: >> >>I am developing a traditional online survey app, the kind of thing >>that alot of people must have done. I am wondering how to protect it >> from script-kiddies who might want to see if they can bombard it >>with fake votes. >> >>It's basically public and anyone can take part in the surveys it will >> run. >> >>I put a switch to check for a flag in the session so that people >>don't vote more than once from the websites where the surveys will be >> deployed. >> >>But I am worried that kids writing scripts will not be stopped by >>session flags. Is it worth writing an algorithm to store the IP >>addresses used for the last hour? Or can they spoof IP addresses? >> >>If it is useful noting the IP addresses, how best should I store >>them? In a hashtable in application scope? In the database? In a >>session EJB? >> >>Thanks! >> >> >> >> >> >>-- struts 1.2 + tomcat 5.0.19 + java 1.4.2 Linux 2.4.20 Debian >> >> >>--------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] For >>additional commands, e-mail: [EMAIL PROTECTED] >> >> >> >>--------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] For >>additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > > -- > struts 1.2 + tomcat 5.0.19 + java 1.4.2 > Linux 2.4.20 Debian > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- struts 1.2 + tomcat 5.0.19 + java 1.4.2 Linux 2.4.20 Debian --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
