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:
- Re: Hashes,File protection,etc, (continued)
- Re: Hashes,File protection,etc Tony (Oct 15)
- Re: Hashes,File protection,etc Roland Postle (Oct 15)
- Re: Hashes,File protection,etc Valdis . Kletnieks (Oct 15)
- Re: Hashes,File protection,etc Roland Postle (Oct 16)
- Re: Hashes,File protection,etc Valdis . Kletnieks (Oct 16)
- Re: Hashes,File protection,etc Bob Mathews (Oct 16)
- Re: Hashes,File protection,etc Jose Nazario (Oct 15)
- Re: Hashes,File protection,etc Valdis . Kletnieks (Oct 15)
- RE: Hashes,File protection,etc Rich Cower (Oct 15)
- Re: Hashes,File protection,etc Eric Fritzges (Oct 15)
- Re: CROSS SITE-SCRIPTING Protection with PHP Sverre H. Huseby (Oct 14)
- Re: CROSS SITE-SCRIPTING Protection with PHP Valdis . Kletnieks (Oct 14)
- RE: CROSS SITE-SCRIPTING Protection with PHP Chris Field (Oct 12)
- Re: CROSS SITE-SCRIPTING Protection with PHP RoMaNSoFt (Oct 12)
- RE: CROSS SITE-SCRIPTING Protection with PHP Rohan Amin (Oct 12)
- Re: CROSS SITE-SCRIPTING Protection with PHP Astalavista.NET Baby! (Oct 14)
- Re: CROSS SITE-SCRIPTING Protection with PHP Dan Kaminsky (Oct 15)
- Re: CROSS SITE-SCRIPTING Protection with PHP Sverre H. Huseby (Oct 16)