[Esapi-dev] LDAP Injection

[Jim Manico]

> P.S.  By the way, I disagree that escaping is not enough to stop XSS. You
just have to do it right.

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