<snip> 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. </snip> 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]
