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]
