struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Hardy <ahardy.str...@cyberspaceroad.com>
Subject Re: [slightly OT] defensive strategy
Date Tue, 13 Apr 2004 20:34:52 GMT
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:ahardy.struts@cyberspaceroad.com]
> 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:ahardy.struts@cyberspaceroad.com] 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: user-unsubscribe@struts.apache.org For
>>additional commands, e-mail: user-help@struts.apache.org
>>
>>
>>
>>---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org For
>>additional commands, e-mail: user-help@struts.apache.org
>>
>>
> 
> 
> 
> --
> struts 1.2 + tomcat 5.0.19 + java 1.4.2
> Linux 2.4.20 Debian
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
> 
> 


-- 
struts 1.2 + tomcat 5.0.19 + java 1.4.2
Linux 2.4.20 Debian


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message