11

We got a security review done of our PHP code and they team advised this in their report (amongst other things):

/appdir/ 

Details
The HTTP header user-agent has been set to \" . 

Request
GET /appdir/ HTTP/1.0 
Accept: */* 
User-Agent: \" 
Host: localhost 
Cookie: PHPSESSID=08rtvlq03bd9d57qor4abjg7q4 
Connection: Close 
Pragma: no-cache 

Response
HTTP/1.1 200 OK 
Date: Sat, 18 Dec 2010 09:35:40 GMT 
Server: Apache/2.2.14 (Win32) DAV/2 mod_ssl/2.2.14 OpenSSL/0.9.8l mod_autoindex_color PHP/5.3.1 mod_apreq2-20090110/2.7.1 mod_perl/2.0.4 Perl/v5.10.1 
X-Powered-By: PHP/5.3.1 
Expires: Thu, 19 Nov 1981 08:52:00 GMT 
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 
Pragma: no-cache 
Connection: close 
Content-Type: text/html

Does it matter that the HTTP header user-agent can be set to \" ?

AviD
  • 72,138
  • 22
  • 136
  • 218
siliconpi
  • 1,087
  • 1
  • 10
  • 20
  • 5
    As a client, in request it is possible to set everything we want. You should ask directly them what they wanted to say with that. At first look I can't get it. It might depend on that how your web application parses headers. –  Dec 22 '10 at 15:18
  • I agree with Ams; it depends on the context in which the user-agent string is used by the application. If, for an egregious example, the user-agent were used without further sanitization in a database query, allowing \" could enable blind SQL injection. – user502 Dec 22 '10 at 15:56
  • How does the Response differ if a proper user-agent is used? – Steve Dec 22 '10 at 16:51
  • @SteveSyfuhs - I dont think we are using it at all in our application... Does it matter to the server? We're using Apache/2.2.3 (CentOS) – siliconpi Dec 22 '10 at 17:36
  • What @Ams said - but I'd go even further and say that whoever did this review is either clueless, or full of crap. Unless they explain it satisfactorily (I have no clue how) - I would say to make a stink. Folks like that give the rest a bad name. (Whats the joke about lawyers? 98% of them give the rest a bad name?) – AviD Dec 23 '10 at 22:55

6 Answers6

10

I dont see how inserting an escaped quotation mark into the user-agent string is a vulnerability.

I'm not certain that this is the case, I think more information is necessary. The ONLY thing I can think of is that they're possibly exposing a potential for a session hijack.

Basically, PHPSESSID=08rtvlq03bd9d57qor4abjg7q4 belongs to a different user's session, they are spoofing this session ID via a cookie, and are getting a normal response, even though the user-agent has changed from the original user.

Clarification:

User A opens the website, using the following User-Agent string:

Mozilla Compatible (MSIE)

User A is then assigned the following session ID:

08rtvlq03bd9d57qor4abjg7q4

User B (bad guy) then sends a request to the server using a cookie with the same session ID in his/her cookie, however their User-Agent string is:

\"

Your application should then realize this is not the same user, and destroy the session.

I am by no means certain this is the situation, nor would monitoring the user-agent prevent a session hijack, as user-agents are EASILY spoofed, but this is the only potential I see here.

Purge
  • 1,996
  • 2
  • 14
  • 26
  • See also http://phpsec.org/projects/guide/4.html and scroll down to the session hijack section for a more in-depth explanation. – Purge Dec 22 '10 at 21:25
  • But then, the vuln should say that! At least, *something* about session management. It reads more like they have no idea how HTTP works... – AviD Dec 23 '10 at 22:57
  • @AViD I agree, hence why I said " I think more information is necessary" and I continued to give an example of a potential issue. I didn't say this IS the cause, or this IS the only potential. Without more information, EVERY answer here is speculation. – Purge Dec 27 '10 at 14:18
9

Injection into the user-agent (or referer for that matter) value can be a potential threat in several ways, however if your current situation is in fact a vulnerability is hard to tell without looking at the bigger picture of your system.

I often see systems that in some way or another uses the user-agent. Often it is used to store information about the most used browser and similar. Sometimes user-agents that are known as bots gets treated differently. There is many cases.

Injection

It is not uncommon to see XSS attacks being tried in the user-agent field. For example a site I was testing some time ago presented me a bits and pieces of information about myself.

The interesting thing was that it outputted the user-agent back to me. When I injected the user-agent 'FooBar"> <img src="javascript:alert('document.cookie')' it alerted it back to me.

Now to leverage this attack onto other users the site had also a stat page where it presented how many average users a day, what the most common browsers were and so on. The numbers seemed to be based on number of requests. Building a quick script which made enough requests with my XSS simply put my user-agent on the top 100 list and the vector was now persistent and working against other users

Same thing is possible for SQL injection. Try run around with useragent Im Harmless";DROP TABLE users. Maybe you break some systems.

Probing for vulnerability

Toss in a /" like in the example and see what happens. Maybe you get an error message, or something happened somewhere else on the site.

Checking out what happens if you use a very old user-agent or a search engine user-agent can sometimes be very useful. Sometimes this is the only way of unlocking some of the content on the site, and probing that content for vulnerabilities.

By using for example Burpsuite the latter is very easy to automate, and then quickly browse all the different requets for differences.

EDIT: In your specific example it seems that the client making the request has set the user-agent to \" . If this is intentionally , a bug or just someone hiding their user-agent is hard to tell, but I would definitely look into other requests made by this user.

Lekensteyn
  • 5,898
  • 5
  • 37
  • 62
Chris Dale
  • 16,119
  • 10
  • 56
  • 97
7

They're trying to sell you something that should be worthless.

HTTP protocol allows for this kind of stuff. I could set the User-Agent (AKA, "What kind of browser are you using?") to "User Agent: User Agent: User Agent: Trust no one"

If your software isn't taking into consideration code injection (SQL, Script, etc...) in a modern way, then this could have been an issue. But you wrote your software using best-practices and have correctly sanitized all inputs and are using a database abstraction layer, right?

In terms of ways to improve your security, monitoring things such as origin, request frequency, profile the requests they make, check user agent, check referrer page, checking ... everything, is an active monitoring you can do to provide more security. I don't believe this is what they were trying to tell you to do (as per part of Alex's answer), just that "You can change this," which is a total "no-duh" to anyone who knows HTTP well enough, but probably just a way to scare up some value-added fluff.

So, if your PHP code allows for any input -including- a user-agent string to be inserted to a DB without being properly sanitized, and use of a database abstraction layer, you're going to have a really bad day.

I'll give you a free tip, your referrer header can be set to this: 

Referrer: \' -- TRUNCATE `Users`

The problem isn't that you can set these headers, you can just as easily submit that data as "Name" in an address form.

So here's the question, do you want to let people who's user-agent you don't have in a table somewhere not use your website? Probably a stupid idea because a hacker can just set it to a valid one anyway.

Incognito
  • 5,204
  • 5
  • 27
  • 31
2

The answer is simple. Don't include any header values passed into the request in the content of your response without first cleansing it. For that matter don't ever use any user supplied data in any way without first cleansing it. Always sanitize inputs.

If you're not including client passed header values in your content then you can ignore this warning.

bahamat
  • 1,061
  • 7
  • 11
2

If the people who are being employed to test the security of your website, and have presumably spent a significant amount of time working on it can't explain how this makes your site in some way vulnerable, but can assert that it is a security weakpoint in your site, then it sounds like you've wasted a lot of time and effort on them. It looks like you've hired script-kiddies to do your pen testing.

There is no advise in the details you've published. There is no analysis.

Also, the fact they seem to be running their tests against 'localhost' suggests they don't know what they're doing.

And

Pragma: no-cache

In a header response suggests that whoever wrote the code doesn't understand HTTP either. From rfc 2616:

Note: because the meaning of "Pragma: no-cache as a response header field is not actually specified, it does not provide a reliable replacement for "Cache-Control: no-cache" in a response

symcbean
  • 18,278
  • 39
  • 73
1

You need to look at your functional spec if they are telling you to validate header fields.

Your functional spec should define what is allowable behavior. It might define any/all user agents as acceptable in which case you need to accept it. Be aware that header data, like all user submitted data, is potentially dangerous.

Bradley Kreider
  • 6,152
  • 2
  • 23
  • 36
  • Could you explain that better @rox0r? How is header data dangerous? – siliconpi Dec 22 '10 at 17:19
  • 4
    I believe that @rox0r is saying that Header data should be treated like any other user submitted data, such as form data, etc. You need to deal with it carefully to avoid SQL injection and XSS vulnerabilities. This doesn't mean you need to disallow requests from user-agents with weird values, but you just need to take the necessary precautions to be sure you don't use that data in an unsanitized manner. – pkaeding Dec 22 '10 at 17:27
  • 1
    its POTENTIALLY dangerous. It depends on how the data is utilized later in the code. Let's assume the user-agent is stored in a database, if left unsanitized it is just another avenue for SQL injection. That is only one possibility. If it isn't used later in the code, it's not a real source of concern. @pkaeding - you beat me to it by seconds! – Purge Dec 22 '10 at 17:28
  • Thanks guys. Yes. all user submitted data is suspect; but only if it is consumed. I can see someone tangential to your project, naively logging all headers to a database. However, IMHO the security alert should be with anyone consuming unsanitized data. – Bradley Kreider Dec 22 '10 at 17:33