[Esapi-dev] LDAP Injection

[Sebastian Kübeck]

Hi!

Am 29.12.2010 05:38, schrieb Jim Manico:
>> P.S.  By the way, I disagree that escaping is not enough to stop XSS. You
> just have to do it right.

Escaping is NOT enough to prevent XSS! Proof:
Four counter examples where escaping "input" doesn't help in any way:

<script type="text/JavaScript">
...
<%=input%>
...
eval(<%=input%>);
...
window.setInterval(<%=input%>);
</script>
<select name="Countries" onchange="<%=input%>">

q.e.d.

-Sebastian Kübeck

> 
> I think it depends on how complex your app is and what context your data is
> getting displayed in. As far as I can tell..
> 
> HTML body context data display can be defended from XSS with escaping alone
> URL contexts data display can be XSSed with the Javascript: url nomenclature
> so you need to **filter** that out
> HTML attribute contexts other than URL's can be defended from XSS with
> escaping alone
> CSS value contexts data display can pop with the Javascript: url
> nomenclature so you need to **filter** that out
> JS contexts can be defended in part with JS escaping, but that JS variable
> can pop depending on where that JS variable is used
> 
> Fair, Jeff?
> 
> 
> -----Original Message-----
> From: Jeff Williams [mailto:jeff.williams at owasp.org] 
> Sent: Tuesday, December 28, 2010 6:17 PM
> To: 'Jim Manico'; 'Kevin W. Wall'
> Cc: 'ESAPI Devs'
> Subject: RE: [Esapi-dev] LDAP Injection
> 
> Your next revelation will be that there are several contexts *within* the
> LDAP syntax, and you're going to want several different methods.
> 
> Then you're going to suggest that it's too complicated and you want an
> automatic escaping system based on some crazy template system.
> 
> --Kreskin
> 
> P.S.  By the way, I disagree that escaping is not enough to stop XSS. You
> just have to do it right.
> 
> 
> -----Original Message-----
> From: Jim Manico [mailto:jim.manico at owasp.org] 
> Sent: Tuesday, December 28, 2010 10:56 PM
> To: 'Jeff Williams'; 'Kevin W. Wall'
> Cc: 'ESAPI Devs'
> Subject: RE: [Esapi-dev] LDAP Injection
> 
> Ah, this makes total sense, Jess. Just like CSS, JS and URL contexts in an
> HTML document, output encoding is not enough to stop XSS. If we just LDAP
> escaped the character, it still *is that dangerous character* which could
> still execute in certain situations.
> 
> By entity encoding, you essentially "removed the character altogether".
> 
> So there is a method to your madness. ;)
> 
> Perhaps we could change this (encodeForLDAP) and just drop the character
> altogether (and not replace it with a whitespace so there is no chance
> untrusted input could help the attacker hop to a new context).
> 
> - Jim
> 
> -----Original Message-----
> From: Jeff Williams [mailto:jeff.williams at owasp.org]
> Sent: Tuesday, December 28, 2010 5:10 PM
> To: 'Kevin W. Wall'; 'Jim Manico'
> Cc: 'ESAPI Devs'
> Subject: RE: [Esapi-dev] LDAP Injection
> 
> Let's not forget that the 'escaping' syntax built into interpreters does not
> necessarily provide protection against injection.  In fact, escaping
> characters may or may not affect whether input can 'inject up' or 'inject
> down' (see the XSS prevention cheat sheet if these terms are not familiar).
> It may just be an alternative syntax for specifying characters with no real
> effect.
> 
> I'm fairly sure that the current approach of escaping non-alphanumeric with
> HTML entities will render injection attacks against LDAP ineffective. We
> could just as easily delete them or replace them with whitespace.  But
> before we change, we should really be sure that we're not inadvertently
> leaving open some injection possibilities.
> 
> Don't get me wrong. Our current approach isn't elegant, and I'd like to see
> it done right. Let's just remember that escaping doesn't always mean what we
> think.
> 
> --Jeff
> 
> 
> -----Original Message-----
> From: esapi-dev-bounces at lists.owasp.org
> [mailto:esapi-dev-bounces at lists.owasp.org] On Behalf Of Kevin W. Wall
> Sent: Tuesday, December 28, 2010 12:07 AM
> To: Jim Manico
> Cc: 'ESAPI Devs'
> Subject: Re: [Esapi-dev] LDAP Injection
> 
> On 12/27/2010 07:46 PM, Jim Manico wrote:
>> Hello,
>>
>> I've been doing work on LDAP Injection prevention, and I think we may 
>> be able to improve the current LDAP encoding function  (it currently 
>> just does HTML entity encoding).
>>
>> Please read
>> http://download.oracle.com/javase/jndi/tutorial/beyond/names/syntax.ht
>> ml - it describes the / escaping methodology needed for LDAP special
> characters.
>> I think this is a better path..
> 
> Yes, this is the proper way to encode things. Unfortunately, it's not quite
> that simple. In Java, how this is done depends at least in part on whether
> you are using JNDI or the Mozilla LDAP SDK. The URL you referred to is
> specific to JNDI. For that reason, OWASP ESAPI is going to have to do this
> in our own encoder without relying on JNDI or Mozilla specific classes
> (e.g., shouldn't use JNDI's Composite class as shown in the example).
> 
> Also, I don't recall if all of these cases cited in the above URL, i.e.,
>     * A space or "#" character occurring at the beginning of the string
>     * A space character occurring at the end of the string
>     * One of the characters ",", "+", """, "\", "<", ">" or ";"
> 
> all apply to the Mozilla LDAP SDK. (Specifically, I don't recall anything
> about either "<" or ">" being special there.)  But the bottom line is, I
> wouldn't assume that it uses the exact same parsing rules, so that needs to
> be checked. The Mozilla LDAP SDK may automatically quote some of these
> things in its parser, so quoting them again could cause problems in that
> then end up in some directory being incorrectly doubly-encoded.
> 
> Because X.509 certificates use X.500 but LDAP can store certificates,
> sometimes '/' also needs to be considered special (especially in the context
> of DNs) because '/' is an X.500 delimiter that mod_ssl (and others?)
> sometimes use for the subject DNs of client certificates. (The '/' character
> is used instead of ',' in X.500.)
> 
> Finally, the first two bullets shown about don't apply unequivocally.
> Specifically, I think they only apply if the "output" representation were to
> be encoded in LDIF (LDAP Data Interchange Format), where leading and
> trailing spaces may be misinterpreted by other parsers (and especially the
> JNDI LDAP
> parser) and a leading # could be interpreted as a comment. (Likewise, I
> would think that for a similar reason you would want to disallow EOL
> terminators such as \r and \n, especially in the context of LDAP injection.)
> However, it is important to note that in some contexts you want to allow
> leading space or '#'
> or a trailing space, and that would be in the case of passwords.
> 
> -kevin
> --
> Kevin W. Wall
> "The most likely way for the world to be destroyed, most experts agree, is
> by accident. That's where we come in; we're computer professionals.
> We cause accidents."        -- Nathaniel Borenstein, co-creator of MIME
> _______________________________________________
> Esapi-dev mailing list
> Esapi-dev at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/esapi-dev
> 
> 
> 
> 
> _______________________________________________
> Esapi-dev mailing list
> Esapi-dev at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/esapi-dev
>