Project

General

Profile

Bug #1330

400 Bad Request when using IP's numeric value ("ip2long()")

Added by Anonymous over 9 years ago. Updated 12 months ago.

Status:
Fixed
Priority:
Low
Assignee:
-
Category:
core
Target version:
Start date:
Due date:
% Done:

100%

Missing in 1.5.x:

Description

Other webservers allow you to access them via their numeric value:

octet1 << 24 OR octet2 << 16 OR octet3 << 8 OR octet4
(or with a calculator, octet1*256^3 + octet2*256^2 + octet3*256 + octet4)

Here's one of Google's IPs:

64.233.167.99
(64 * (256^3)) + (233 * (256^2)) + (167 * 256) + 99
1089054563

So if you use http://1089054563 --- you get to google.

If you try this with a server running lighttpd, you get "400 Bad Request" :)

This is an old trick to get by proxies. I doubt it works any more...but what good is it to get by a proxy if you're trying to reach a lighttpd hosted website!? :D

Great job on lighty, btw, excellent software!

-- Ben <ben_is_a

Associated revisions

Revision b47494d4 (diff)
Added by gstrauss about 1 year ago

[config] opts for http header parsing strictness (fixes #551, fixes #1086, fixes #1184, fixes #2143, #2258, #2281, fixes #946, fixes #1330, fixes #602, #1016)

server.http-parseopt-header-strict = "enable"
server.http-parseopt-host-strict = "enable" (implies host-normalize)
server.http-parseopt-host-normalize = "disable"

defaults retain current behavior, which is strict header parsing
and strict host parsing, with enhancement to normalize IPv4 address
and port number strings.

For lighttpd tests, these need to be enabled (and are by default)
For marginally faster HTTP header parsing for benchmarks, disable these.

To allow
- underscores in hostname
- hypen ('-') at beginning of hostname
- all-numeric TLDs
server.http-parseopt-host-strict = "disable"

x-ref:
"lighttpd doesn't allow underscores in host names"
https://redmine.lighttpd.net/issues/551
"hyphen in hostname"
https://redmine.lighttpd.net/issues/1086
"a numeric tld"
https://redmine.lighttpd.net/issues/1184
"Numeric tld's"
https://redmine.lighttpd.net/issues/2143
"Bad Request"
https://redmine.lighttpd.net/issues/2258
"400 Bad Request when using Numeric TLDs"
https://redmine.lighttpd.net/issues/2281

To allow a variety of numerical formats to be converted to IP addresses
server.http-parseopt-host-strict = "disable"
server.http-parseopt-host-normalize = "enable"

x-ref:
"URL encoding leads to "400 - Bad Request""
https://redmine.lighttpd.net/issues/946
"400 Bad Request when using IP's numeric value ("ip2long()")"
https://redmine.lighttpd.net/issues/1330

To allow most 8-bit and 7-bit chars in headers
server.http-parseopt-header-strict = "disable" (not recommended)

x-ref:
"Russian letters not alowed?"
https://redmine.lighttpd.net/issues/602
"header Content-Disposition with russian '?' (CP1251, ascii code 255) causes error"
https://redmine.lighttpd.net/issues/1016

History

#1 Updated by Anonymous over 9 years ago

Errr, this (#)&$ing wiki screwed up my formatting...I should've previewed first! Here are the relevant pieces:

(or with a calculator, octet1*256^3^ + octet2*256^2^ + octet3*256 + octet4)

64.233.167.99 (64 * (256^3^)) + (233 * (256^2^)) + (167 * 256) + 99 1089054563

-- Ben <ben_is_a

#2 Updated by carpii about 1 year ago

Not a valid bug (maybe it was at the time)

The octet address is decoded to an IP before the connection is even made to lighttpd
The HTTP Host header still specifies the octet hostname, but lighty treats this as an abritrary string anyway..

For my test IP of 192.168.1.79....

$HTTP["host"] == "3232235855" {
url.redirect = ( "^/(.*)" => "http://google.com" )
}

$ wget http://3232235855

--2016-05-03 00:06:09-- http://3232235855/
Resolving 3232235855... 192.168.1.79
Connecting to 3232235855|192.168.1.79|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://google.com [following]

#3 Updated by gstrauss about 1 year ago

  • Description updated (diff)

There are a number of open issues related to the feature request of lighttpd parsing various formats of numerical strings in the Host header into an IP address that is then used for condition matching. request.c:request_check_hostname() is the place where many of these are rejected. I was thinking that a new config switch (or switches) might disable the strict checks here, and/or parse various numerical formats into IP strings.

#4 Updated by gstrauss about 1 year ago

  • Status changed from New to Patch Pending
  • Assignee deleted (jan)
  • Target version set to 1.4.40

#5 Updated by gstrauss 12 months ago

  • Status changed from Patch Pending to Fixed
  • % Done changed from 0 to 100

Also available in: Atom