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 22:14:16 GMT
You're right, that's exactly what they're for and I do use them for 
normal transactions - it just took a paradigm shift for me to recognise 
this voting process as a transaction!

On 04/13/2004 10:42 PM Andrew Hill wrote:
> <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:ahardy.struts@cyberspaceroad.com]
> 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: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
> 
> 
> 
> ---------------------------------------------------------------------
> 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