You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Adam Hardy <ah...@cyberspaceroad.com> on 2004/04/13 12:22:49 UTC
[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
RE: [slightly OT] defensive strategy
Posted by Daniel Perry <d....@netcase.co.uk>.
Thats not a bad idea. Not entirely foolproof, but would take a significant
amount of work to cheat the system, and would probably put any cheating
attempts off.
One suggestion i would have, is that a good stratergy (as with most security
issues) is to give away as little information as possible. So if a vote is
detected as a duplicate, then still give the response as if it had been
accepted. This slows down any progress made on cracking your system.
Daniel.
-----Original Message-----
From: Adam Hardy [mailto:ahardy.struts@cyberspaceroad.com]
Sent: 13 April 2004 12: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
RE: [slightly OT] defensive strategy
Posted by Andrew Hill <an...@gridnode.com>.
hehe. Glad to be of service. :-)
-----Original Message-----
From: Adam Hardy [mailto:ahardy.struts@cyberspaceroad.com]
Sent: Wednesday, 14 April 2004 06:14
To: Struts Users Mailing List
Subject: Re: [slightly OT] defensive strategy
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
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [slightly OT] defensive strategy
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
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
RE: [slightly OT] defensive strategy
Posted by Andrew Hill <an...@gridnode.com>.
<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
Re: [slightly OT] defensive strategy
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
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
RE: [slightly OT] defensive strategy
Posted by Andrew Hill <an...@gridnode.com>.
<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: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
Re: [slightly OT] defensive strategy
Posted by Adam Hardy <ah...@cyberspaceroad.com>.
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
RE: [slightly OT] defensive strategy
Posted by Daniel Perry <d....@netcase.co.uk>.
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.
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!
If you are really concerned with it, then put a limit on number of requests
from an ip like you suggest.
The most secure method i would suggest is to store each vote in the database
with the ip. Converting the IP to an int will speed things up a lot! You can
then implement a limiter and take a proactive blocking approach, or add an
alerter, and take a reactive approach to mass votes!
Daniel.
-----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