Understood. Really appreciate for your nice time.


Thanks,


At 2015-05-20 21:00:33, "Christopher Schultz" <ch...@christopherschultz.net> 
wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA256
>
>
>
>On 5/20/15 4:22 AM, javalishixml wrote:
>> More detail information as below:
>> 
>> presudo-code step:
>
>This isn't pseudo-code. This is a re-statement of your problem.
>
>> 1. a register page named "http://mywebsite.com/register1.jsp"; is
>> set up, and this page contains a CAPTCHA image
>
>You didn't mention that CAPTCHA was already being used. Someone
>mentioned using it as a solution to your problem. What CAPTCHA are you
>using? Perhaps using a more effective one would help more than
>anything else.
>
>> 2. the robot(crackers) could successfully register the thousands 
>> different users for this web site during only several minutes.
>> 
>> 3. if it is a human beings, these thousands different users should 
>> have different IPs. But we find these thousands different users
>> are from same IPs.
>
>No chance these are AOL users? Google for "AOL ip address proxy".
>
>> By the way, we get the IP from HttpServletRequest header.
>
>Where else would you get the remote IP address?
>
>> 4. later, we setup a new register page. We change its url from 
>> "http://mywebsite.com/register1.jsp"; to 
>> "http://mywebsite.com/register2.jsp";
>
>Are you trying to be evasive? Why have you moved your registration page?
>
>> For the first several days, we find everything is good.
>> 
>> But after several days, we find the robot(crackers) find this new 
>> URL and could successfully register the thousands different users
>> for this web site during only several minutes.
>> 
>> It's just reproduced steps for our issue.
>
>So, back to my original question: How are you going to identify a
>"duplicate" request? Show some pseudo-code.
>
>> Our requirements are that: 1. we have a URL for register page. we
>> don't want the thousands different users with same IP could
>> successfully registered during a very short time window.
>
>What about users behind proxies? Are you okay shutting them out? See
>the AOL anecdote above.
>
>> 2. We can have a policy to set an interval time window. Based on
>> this interval time window, the same IP should NOT register users
>> again and again.
>> 
>> 3. This policy should manage a group of URLs. We can always add
>> the different URLs for this policy. Because based on our
>> maintaining activities, we may set up many different register page
>> again and again.
>> 
>> 
>> Is it a DDOS attack?
>
>Are they preventing anyone else from using your site? Or are they just
>raising their numbers quickly enough that statistically, they always
>overwhelm your legitimate users and "win" the "lottery"?
>
>> Is there a good way to resolve it at httpd level?
>
>Seriously, look-up mod_qos, mod_evasive, and mod_security and stop
>asking for solutions. We've already given you a whole bunch of ideas
>that consultants would have already bankrupted you for. Go do some work.
>
>- -chris
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v2
>Comment: GPGTools - http://gpgtools.org
>
>iQIcBAEBCAAGBQJVXIVxAAoJEBzwKT+lPKRY3AMQAIWrelhsrB9WnB8c+Wq7S2ia
>+L1dU+ZTI+VEeFBWy1ARUTtXM/viL7mE7QfofVVEjmMYAxrITrk9Nqn0DzmGBJAG
>JNcPkSHVAvhH9thOJDCfLvD69hV5sGCJdNC6RlYn235IEiai1IhH6ZQudrCXAPjl
>mMjZPX30W65MbA7fBMWG4NUJFi2BBz07zV8/teIwHQ/3w9fTs63o18alRwP5cGUk
>i1yu0lBf63xO5r7xnS5jN9fvklZe6FrCS+6RK2AAj2viF7mGi3kmaco1fdSQmTLY
>rdadMd0M9P6BgowMtBUAVNX4DnqJc2GIo8xlCySC/myvp8y3T9vwOvyRERoSW+8h
>a7oEPV6SKlFYKLHNg0XVgmkT3PHTjqojh2eOlKh8vO3W5YTw2R3xqXa4WUN0dHur
>cbD2RjSm7mA0Ewl+E2YsCbJAdfuPt3w77mIuv3FaV6ZPWdXLtSq0QARfGju0S11x
>bdEBaOzsQsm29qOC5MKMqG0tgHlY1Ya3BnGGxI+GTMat91d8kp92ufWeS5bmda3I
>BqOosM+GkgY9P1DATPXpR5A8Xi5Pp/lgkD4MYVNka2VH7FgKWckXlUhWoilDqFDX
>k4R9z/ZaRrDwqt6lwSAlRN4znwTw0OyP9FSLGr+VIKfKRUyweJss6pVUUGpxd3yQ
>ytK9Cbw2UpbOyFaiA1AE
>=CHtu
>-----END PGP SIGNATURE-----
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: users-h...@tomcat.apache.org
>

Reply via email to