OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [saml-dev] SAML 2.0 DOS attacks

Hi Conor.
Thanks for your tipps.
Your bullet number 1 seems reasonable.
Regarding bullet 2, I am not sure, since an attacker who knows the ID's of the legitimate SP's could type it herself. In order to verify the legitimacy of ID, one would need to verify signatures on the assertion, which is a relatively computationally heavy operation, and can lead to DOS attacks as well.
Third bullet seems fine too :).
Fourth one, as I understood, suggests, in case of heavy processing load on IDP, prior to validating any assertion, IDP should directly authenticate the users who carry these assertions, that makes sense --if user authentication is less computationally expensive operation than verifying the assertion validity; which I doubt--, however only in the case, when the IDP's sole purpose is user authentication, else a typical IDP would need a means to differentiate whether the user is redirected to her as a part of SSO session, or is just doing some surfing.
Best Regards,

"Cahill, Conor P" <conor.p.cahill@intel.com> wrote:
I haven’t done any deep research on responding to DOS attacks at a SAML IdP so take some of this with a grain of salt, but some of the SAML related kinds of things I think might be useful could include:
·         Validate that the incoming request is reasonably sized *before* handing it to any parsing module.  One of the easiest DOS attacks is to send large XML messages that get parsed before validation.   A reasonably sized AuthnRequest is pretty small.
·         Validate the SPProviderID is one of the SPs with which the IdP is willing to federate with (e.g. is in the circle of trust) before doing anything else with the message
·         Give scheduling preference to incoming requests that come with session information from the IdP (e.g. they are associated with an existing session at the IdP via some cookie you stored in the browser) these are less likely to be part of the DOS attack.
·         If the threat level is increasing at the IdP (e.g. your processing load at the IdP is getting near DOS stage) you might want to prompt for successful user authentication prior to signing the message and possibly even prior to parsing the incoming request as the validation of the credential could be a much lower cost request/response than dealing with.   I wouldn’t do this as a normal course of business as it could result in less than optimal user experience, but it may be a good reaction to a concerted attack that will allow you to still give a reasonable level of service to the users who can authenticate.
And, of course, there’s all the standard DOS prevention techniques you can use that are not SAML specific (rate limiting, etc.).
From: giorgi moniava [mailto:giorgimoniava@yahoo.com]
Sent: Friday, June 06, 2008 5:41 AM
To: saml-dev@lists.oasis-open.org
Subject: [saml-dev] SAML 2.0 DOS attacks
I would like to ask one question if possible.
Namely, how can and IdP protect against DOS attacks,
by restricting allowed authentication requests from certain
SP's, when an attacker can easily spoof IP addresses? --
i.e. is there another way, to limit the set of SP's that can initiate user authentication with the IdP? (I don't look at the cases hen one can use IPSec, in order to prevent spoofing IP addresses-- that's one answer I guess, but I wonder if there are other ways as well).

Thank you.
Kind Regards,

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]