US-ASCII bei HTTP - MSB lassen oder leeren?



  • Ich schreibe gerade einen HTTP-Parser in C und verwende als Referenz den RFC7230. Im Grunde funktioniert bereits alles, aber über eine Sache bin ich gestolpert:

    3.2. Header Fields

    Each header field consists of a case-insensitive field name followed
    by a colon (":"), optional leading whitespace, the field value, and
    optional trailing whitespace.

    Für das schnelle Suchen der Content-Länge suche ich in der Header-Sektion der Nachricht derzeit nach "\r\nContent-Lenght:". Da das RFC aber verlangt, dass Groß- und Kleinschreibung ignoriert werden soll, wollte ich ein memmem nach Boyer-Moore schreiben, welches case-insensitive ist, also vorher alles in Kleinbuchstaben konvertiert (Sprungtabelle und Buchstabensuche). Für die Bestimmung, ob es sich um einen Groß- und Kleinbuchstaben handelt, und die Konvertierung in das jeweils verwende ich ein paar selbstgeschriebene Makros, weil ich im Grunde nur mit ASCII arbeite.

    Mein Problem ist folgendes: Um 8-Bit-clean zu sein, sollte ich vor jedem Vergleich das Most Significant Bit löschen. Allerdings kann es sein, dass ein Angreifer statt den Buchstaben "A" einfach 0xc2 (Buchstabe A plus MSB) sendet und mein Parser ein eigentlich verbotenes Zeichen als Buchstaben behandelt, welches dann zum Beispiel als Content-Länge interpretiert wird.

    Meine Frage ist: Sollte ich das MSB vor jeder Prüfung löschen, prüfen, ob es sich um einen Wert größer 0x7f handelt, oder einfach ignorieren? Ich konnte in dem RFC keine weiteren Referenzen hieraus ziehen.

    Vielen Dank.



  • Ich verstehe nicht ganz warum Du das MSB löschen willst. Wenn Du einen kaputten #Header bekommst, dann würde ich den einfach ablehnen.

    mfg Martin



  • Weil das RFC5234 und RFC7230 verlangen, dass die Kodierung wie folgt ist:

    Externally, data are represented as "network virtual ASCII" (namely,
    7-bit US-ASCII in an 8-bit field), with the high (8th) bit set to
    zero. A string of values is in "network byte order", in which the
    higher-valued bytes are represented on the left-hand side and are
    sent over the network first.

    Mir geht es darum, einen Parser zu schreiben, der mit dem neuen RFC zu HTTP kompatibel ist.



  • dachschaden schrieb:

    Weil das RFC5234 und RFC7230 verlangen, dass die Kodierung wie folgt ist:

    Externally, data are represented as "network virtual ASCII" (namely,
    7-bit US-ASCII in an 8-bit field), with the high (8th) bit set to
    zero. A string of values is in "network byte order", in which the
    higher-valued bytes are represented on the left-hand side and are
    sent over the network first.

    Mir geht es darum, einen Parser zu schreiben, der mit dem neuen RFC zu HTTP kompatibel ist.

    Das heißt aber nicht, daß DU es löschen mußt, sondern, daß der Sender es nicht verschicken darf.

    mfg Martin



  • Ich würde auch nicht nach einzelnen Header Feldern suchen, sondern erstmals den ganzen Header parsen - hier darf eh kein spezielles Encoding verwendet werden. Wenn du ungültige Bytes findest, einfach 400 Bad Request antworten.

    Und dann wenn du den Header hast, kannst du easy lookups auf Content-Length und Co machen. idR speichert man die Header nämlich einfach als lowercase und fertig 🙂



  • Shade Of Mine schrieb:

    erstmals den ganzen Header parsen (...) dann wenn du den Header hast, kannst du easy lookups auf Content-Length und Co machen

    +1
    Ich sehe auch keinen Sinn darin erstmal mit nem speziellen Code die Content-Länge zu suchen.
    Die Headers muss man ja sowieso parsen wenn man den Request beantworten will.


Log in to reply