NYCPHP Meetup

NYPHP.org

[nycphp-talk] Preferred method for parsingmulti-row submitbuttons

Hans Zaunere lists at zaunere.com
Tue Nov 22 11:27:11 EST 2005



Chris Shiflett wrote on Monday, November 21, 2005 11:05 PM:
> Hans Zaunere wrote:
> > But this certainly shouldn't be considered a real practice.
> 
> HTTP isn't something to violate on a whim, and adhering to it is a real
> practice.

Standards are important, and vital to the internet. But RFCs aren't perfect,
and knowing when the real-world comes into play, is just as vital.

> > While RFCs are good academically, that's how security holes
> > are born.
> 
> Care to substantiate that?

Sure -

A search for rfc exploit brings up a lot, but here's actually an RFC that
explains just such a thing.  There are a number of exploits listed, but
section 3, Tiny Fragment Attack is:

---
   STD 5, RFC 791 states:

      Every internet module must be able to forward a datagram of 68
      octets without further fragmentation.  This is because an internet
      header may be up to 60 octets, and the minimum fragment is 8
      octets.

   Note that, for the purpose of security, it is not sufficient to
   merely guarantee that a fragment contains at least 8 octets of data
   beyond the IP header because important transport header information
   (e.g., the CODE field of the TCP header) might be beyond the 8th data
   octet.
---

Here RFC 791, which in fact has been elevated to standard status, is cited
as not sufficiently describing behavior for the purpose of security.

And, perhaps one of the most famous, which proved exploitable by a
combination of implementation issues and assumptions about what people would
do with a protocol.

http://damaged.crontab.org/pub-dir/texts/s/sequence_attacks.txt

So not to get philosophical, but adhereing to a standard without considering
undocumented "what if" scenarios, is exactly what hacking and security is
all about.  People will bend the standards, and to keep yourself protected,
you need to bend them beforehand.

---
Hans Zaunere / President / New York PHP
   www.nyphp.org  /  www.nyphp.com





More information about the talk mailing list