Názory k článku
Chyba v Pythonu v knihovně ipaddress
-
The following constitutes a valid IPv4 address:
A string in decimal-dot notation, consisting of four decimal integers in the inclusive range 0–255, separated by dots (e.g. 192.168.0.1). Each integer represents an octet (byte) in the address. Leading zeroes are not tolerated to prevent confusion with octal notation.
An integer that fits into 32 bits.
An integer packed into a bytes object of length 4 (most significant octet first).
>>>
ipaddress.IPv4Address('192.168.0.1')
IPv4Address('192.168.0.1')ipaddress.IPv4Address(3232235521)
IPv4Address('192.168.0.1')ipaddress.IPv4Address(b'\xC0\xA8\x00\x01')
IPv4Address('192.168.0.1')Changed in version 3.8: Leading zeros are tolerated, even in ambiguous cases that look like octal notation.
Changed in version 3.10: Leading zeros are no longer tolerated and are treated as an error. IPv4 address strings are now parsed as strict as glibc inet_pton().
Changed in version 3.9.5: The above change was also included in Python 3.9 starting with version 3.9.5.
asi by to mělo znovu začít vyhazovat chybu, určitě lepší varianta, než předpokládat, že uživatel chtěl vlastně napsat něco jiného
-
Nejde spíš o to, že by ti nějaký software vnutil řetězec s adresou 010.x.x.x, validátor ho vyhodnotil jako 10.x.x.x, tedy lokální síť, polevil v pozornosti, dovolil další zpracování systémem, který by to přeložil jako 8.x.x.x a provedl pro externí adresu něco, co má dělat jen pro lokální?
Čili by reálně psal ipv4 adresu jinak než decimálně útočník, který by chtěl zneužít téhle chyby. Zvlášť pokud byla i perlu a npm.
-
inet_aton je docela peklíčko, desítky let si ho neseme s sebou, všechny varianty nejsou ani správně ve standardech a je v tom spousty skrytých triků, jednotlivé implementace jsou rozdílné a je to prostě minové pole na podobné chyby.
S ipv6 tenhle problém již není a je jasně specifikováno jaké může mít varianty.
