Vulnerability Development mailing list archives

Re: CROSS SITE-SCRIPTING Protection with PHP


From: "Sverre H. Huseby" <shh () thathost com>
Date: Mon, 14 Oct 2002 20:27:49 +0200

[Valdis Kletnieks]

|   And you verify that the digest isn't changed *how*?  (Hint - how
|   do you keep your attacker from handing you a piece of data along
|   with a digest that matches?

We are talking about data that is taking a round-trip to the client in
eg. a hidden field.  I think it is common to take one of two following
approaches:

  1. Add a digest based on a _server_side_secret_ prepended to the
     data.  An attacker won't be able to correctly create a matching
     digest, unless he also knows the server side secret.

  2. Don't pass the data in clear at all, but rather pass it
     encrypted.  Encryption is of course done using a password only
     known at the server.

Of course, the best thing is not to pass the data at all (keep it on
the server), but that's not always possible.

|   >   * Automatically checking the length of input where possible.
|   
|   In general, not doable outside of a strongly typed language - how
|   does the API "know" that the maximum allowed length of a string is
|   37?

It must be stated somewhere, of course.  Lengths are often stated
somewhere.  In the database definition for instance (if we're talking
about databases).  Personally, I think it would be a good idea to
describe the data model in such a generic format that it would be
possible to:

  * build CREATE TABLE statments from it

  * generate code that eg. checks length and type restrictions from it

Change the data model, type "make", and everything works as expected.

|   Note that this is particularly tricky if (for instance) you're
|   writing in Perl, which doesn't have an inherent maximum length,
|   but you're eventually passing it to an Oracle database that has
|   '37' as the length..

Why is it tricky?  If you're somehow able to force the input through
substr($input, 0, 37), you have restricted it's length.

I'm quite certain I wouldn't create the new platform I'm dreaming
about with Perl as the basis, though.

|   Hmm.. and the LDAP schemas, and the Oracle table definitions,
|   and.....  It's a lot harder to do than it looks

Yes, I know.  Otherwise I would have built this platform two years ago
when I started playing with parts of it in my head.

|   and usually just having good programming standards will do 95% of
|   what's needed....

Yes, but then you need the programmers to understand why those
standards are in place, and why they should never, for any reason,
write code that conflicts the standards.  My experience is that in
larger projects with many programmers on and off, that isn't doable.


Sverre.

-- 
shh () thathost com             Computer Geek?  Try my Nerd Quiz
http://shh.thathost.com/        http://nerdquiz.thathost.com/


Current thread: