[NEWSENDER] - Re: Is there a way to protect login page against a frequent submit? - Message is from an unknown sender
Li Wei Nan
liweinan at chinaedu.net
Fri Feb 8 12:38:42 EST 2008
Thank you all for your advices, it's really give me a lot of
inspirations :-)
Considering that most of our clients are in-home guys using ADSL
instead of sitting behind a firewall of a big company, the chance
they share same IP address are rather small. So it may suitable for
me to use "ThrottledSubmissionByIpAddressHandlerInterceptorAdapter"
for now.
I think both 'IP' and 'User' way have their pros and cons.
Ole's concept for banning the submission by user is an alternative
way to achieve the similar goal. And it may give user a better
experience.
From Ole's reply I didn't find the impl method to identify each
'user', I guess it's using the session or the 'username' the user
entered in the login form.
No matter how it's implemented, banned the request by 'user' has
another problem: it cannot protect the CAS server from DDOS attack,
if an attacker write a tcp program and sending a large amount of
random generated username/password(and surely he/she can re-establish
session each time), the server cannot recognize it as the same user
and it will have to deal with those garbage infos, and make server
stop responding to normal users - actually that's what really
happened in our company recently.
The IP way is obviously safer under this circumstance. Certainly if
the attcker is really working hard, the IP address can also be faked,
but our firewall can
detect most of those forged tcp packages.
So, In my opinion, the IP way is safer and the 'User' way is better
in user experience. For OUR COMPANY, since the CAS server now bearing
a dozen of universites login request, and considering the DDOS attack
happened before, I think
ThrottledSubmissionByIpAddressHandlerInterceptorAdapter is enough for
OUR COMPANY's PURPOSE.
BTW, The following default value in
ThrottledSubmissionByIpAddressHandlerInterceptorAdapter seems
resonable to make it function properly. 100 thresshold will be enough
for us even if behind one IP there's hundreds of users.
/** Default value for the failure threshhold before you're locked
out. */
36
private static final BigInteger DEFAULT_FAILURE_THRESHHOLD =
BigInteger
37
.valueOf(100);
38
39
/** The default timeout (in seconds) to clear one failure
attempt. */
40
private static final int DEFAULT_FAILURE_TIMEOUT = 60
I'll try to use
ThrottledSubmissionByIpAddressHandlerInterceptorAdapter soon and if
there's any problem I'll report it here :-)
Thank you all for your helps~~
Best Regards,
Li Wei Nan
Le 2008-2-9 à 上午12:15, Ole Ersoy a écrit :
> I've been toying with the idea of making a filter as well. I think
> it could be done by creating a CAS ServletContextLister that
> creates a data structure for storing:
>
> - user
> - number of attempts
> - time of last attempt
>
> The filter then grabs this data structure from the CAS
> ServletContext and uses it like this:
>
> If a user has made an attempt to login within say the last 15
> minutes, the number of attempts is incremented, given that it's not
> already at the max. If it's at the max then the user gets a
> message saying that they have to wait X minutes before trying to
> login again. If the user has made a login attempt before, but the
> attempt was made more than 15 minutes ago, then the filter resets
> the number of attempts to 1, and the cycle starts over again.
>
> If this were made as a component to CAS it should probably be an
> Action that is invoked before the initialFlowSetup. So if user is
> allowed to attempt to login, then the next step is the
> initialFlowSetup, otherwise it's the too many attempts view-state.
>
> Cheers,
> - Ole
Le 2008-2-8 à 下午11:48, Ole Ersoy a écrit :
> Scott,
>
> I did some research a while back, and one of the concerns regarding
> restrictions by IP is that a large number of users may sit behind a
> common IP / gateway / proxy, and that that IP will come through as
> the IP doing something funky. So if that IP is blocked, then
> there's a possibility that other users will be automatically
> blocked as well. Do you know if the interceptor mentioned below
> solves this concern by chance?
>
> Thanks,
> - Ole
>
>
>
>
> Scott Battaglia wrote:
>> You may be able to use something like this:
>>
>> http://developer.jasig.org/source/browse/jasigsvn/cas3/trunk/cas-
>> server-core/src/main/java/org/jasig/cas/web/support/
>> ThrottledSubmissionByIpAddressHandlerInterceptorAdapter.java?r=42053
>>
>> It hasn't been heavily tested but its supposed to restrict number of
>> requests by IP Address. If you do try and use it, please feel
>> free to
>> provide us with any feedback or improvements :-)
>>
>> -Scott
>>
>> On Feb 8, 2008 12:03 AM, ??? <liweinan at chinaedu.net
>> <mailto:liweinan at chinaedu.net>> wrote:
>>
>> Thanks for your advice Ole, I've done some researches on
>> Geronimo and it
>> seems overkill to me.
>> It seems best for me to write a simple filter using session to
>> control the
>> attempting.
>>
>> Thanks,
>> Li Wei Nan
>>
>> ----- Original Message -----
>> From: "Ole Ersoy" <ole.ersoy at gmail.com
>> <mailto:ole.ersoy at gmail.com>>
>> To: "Yale CAS mailing list" <cas at tp.its.yale.edu
>> <mailto:cas at tp.its.yale.edu>>
>> Sent: Friday, February 08, 2008 4:26 AM
>> Subject: Re: Is there a way to protect login page against a
>> frequent
>> submit?
>>
>>
>>> Hi Li,
>>>
>>> You can do this with a servlet filter that intercepts cas login
>> requests.
>>> You would have to get the principal user, see if they have
>> attempted to
>>> login with a specified time period, and redirect them to another
>>> page
>>> explaining that they have made too many login attempts and that
>> they must
>>> wait X minutes before attempting again. I think Geronimo has
>> something
>>> like this built in, but I'm still looking around for a standalone
>>> implementation.
>>>
>>> Cheers,
>>> - Ole
>>>
>>>
>>>
>>> Li Wei Nan wrote:
>>>> Hi Everyone,
>>>>
>>>> Is there a plug-in or something like custom view could be used in
>>>> cas-webapps to protect cas from malicious credential/principal
>> sniffer?
>>>>
>>>> Or maybe there's some configuration I can do in tomcat to achieve
>>>> this goal which I don't know yet?
>>>>
>>>> Thank you for your helps,
>>>>
>>>> Li Wei Nan
>>>> _______________________________________________
>>>> Yale CAS mailing list
>>>> cas at tp.its.yale.edu <mailto:cas at tp.its.yale.edu>
>>>> http://tp.its.yale.edu/mailman/listinfo/cas
>>>>
>>> _______________________________________________
>>> Yale CAS mailing list
>>> cas at tp.its.yale.edu <mailto:cas at tp.its.yale.edu>
>>> http://tp.its.yale.edu/mailman/listinfo/cas
>>>
>>
>>
>> _______________________________________________
>> Yale CAS mailing list
>> cas at tp.its.yale.edu <mailto:cas at tp.its.yale.edu>
>> http://tp.its.yale.edu/mailman/listinfo/cas
>>
>>
>>
>>
>> --
>> -Scott Battaglia
>> PGP Public Key Id: 0x383733AA
>> LinkedIn: http://www.linkedin.com/in/scottbattaglia
>>
>>
>> ---------------------------------------------------------------------
>> ---
>>
>> _______________________________________________
>> Yale CAS mailing list
>> cas at tp.its.yale.edu
>> http://tp.its.yale.edu/mailman/listinfo/cas
> _______________________________________________
> Yale CAS mailing list
> cas at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas/attachments/20080209/b1a29f0f/attachment.html
More information about the cas
mailing list