Wednesday, September 27, 2023
 Popular · Latest · Hot · Upcoming
rated 0 times [  12] [ 0]  / answers: 1 / hits: 13872  / 2 Years ago, wed, may 26, 2021, 11:10:57

I have many attempts on my (small, personal and absolutely unimportant) web server, and apache and fail2ban usually do their job right. But there's a log entry that worries me:

xx.yy.www.zzz - - [9/Jul/2011:12:42:15 +0100] "GET HTTP/1.1" 200 432 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv: Gecko/20080201 Firefox/"

The problem is answer wasn't a 404 code, but a 200 instead. Is that okay? Seems weird to me, but my knowledge on this field (and many others) is, to put it softly, limited.

More From » server


First, up front, I don't know what the presumed attacker is trying to accomplish. Maybe there's a PHP script or PHP version out there vulnerable to some strange session ID attack, I dunno. You probably have nothing to worry about, though.

Your server behaved exactly as expected. 200 is the expected code in that particular situation because of how Apache interprets the URL being passed to it.

First, is treated like the more usual 'Host:' header (note that I don't think this is specified in the RFC and other servers may not interpret it this way I was wrong, this is specified in RFC 2616 in section 5.1.2, even though clients rarely seem to use that form. Excuse me, I need to go fix an HTTP server implementation I wrote a while back...).

Now, presumably you don't have a site named ''. So what happens when Apache gets a Host: header (or equivalent) for a hostname it doesn't recognize? It picks the first virtual host as the default. This is well-defined and documented behavior for Apache. So whatever your first virtual host is (or just the main server configuration if there aren't any vhosts) takes over, no matter what it's named.

Now, the rest of the URL given consists of two parts -- the path, /, and a GET parameter (the ?PHPSESSID... bit).

Now, the path / should be present on pretty much every web server out there. In most cases, it maps to something like index.html or perhaps an index.php script, though you can override any of this of course.

If it maps to a static HTML file, absolutely nothing unusual happens -- the contents of the file are returned, and that's that, the parameter is simply ignored. (Assuming you don't have certain advanced configuration directives set, and you almost certainly don't.)

On the other hand, if it's a script of some sort, that PHPSESSID variable will get passed to the script. If the script actually uses that variable (in this particular case, only PHP scripts using PHP's built-in session handling are likely to), its behavior will depend on the contents.

In all likelihood, however, even if your / happens to map to a PHP script using sessions, nothing remarkable will happen. The session ID probably won't exist anyway, and will either be ignored, or the script will show an error.

In the unlikely case that the session ID does exist, well, the attacker could conceivably hijack someone else's session. That would be bad, but it's not really a security hole in itself -- the hole would be wherever the attacker got the session ID information from (sniffing a wireless network is a good candidate if you're not using HTTPS). They wouldn't actually be able to do anything that the user whose session it originally was couldn't do.

Edit: Additionally, the '%5C' inside the SESSIONID maps to a backslash character. This seems to be a test for directory traversal attacks on windows hosts.

[#44268] Friday, May 28, 2021, 2 Years  [reply] [flag answer]
Only authorized users can answer the question. Please sign in first, or register a free account.

Total Points: 307
Total Questions: 103
Total Answers: 119

Location: Bosnia and Herzegovina
Member since Thu, Jun 24, 2021
2 Years ago
tisglitter questions
Sun, Jan 9, 22, 16:18, 2 Years ago
Tue, Jan 10, 23, 00:08, 9 Months ago
Wed, Jun 1, 22, 18:03, 1 Year ago
Fri, Dec 10, 21, 14:31, 2 Years ago