MySQL injection & PHP question

[icydash]

Hey all,

 

I'm in the middle of coding a forum for fun and a question popped up.  I created the usual textarea so that users can input the content they want to post on the forum, and it saves whatever they input to a MySQL table.  I was then trying to see if I could break it (to make it more secure), and tried to input as my post "<?php echo $REMOTE_ADDR; ?>" just to see what would happen.  It indeed saved "<?php echo $REMOTE_ADDR; ?>" to the MySQL table in the right spot; however, unexpectedly, when I viewed the post, instead of the forum actually running the <?php echo $REMOTE_ADDR; ?> command and displaying my IP like I expected, it literally just output "<?php echo $REMOTE_ADDR; ?>".

 

So I guess my question is:  what happened?  Why isn't it running the php code like I thought it would?  Is there a way to get it to run the PHP code that I'm not thinking of?

[xyph]

PHP code in a string will not be executed unless it's in an exec() call.

 

JavaScript is what you should be worried about

[icydash]

Oh... really?  Well I guess I'm accidentally pretty safe then, haha.

 

As to JavaScript, other than being annoying (e.g. inserting code that has like 10000 alerts), could anyone actually do anything dangerous to compromise the security of the site / my server?

[xyph]

Oh... really?  Well I guess I'm accidentally pretty safe then, haha.

 

As to JavaScript, other than being annoying (e.g. inserting code that has like 10000 alerts), could anyone actually do anything dangerous to compromise the security of the site / my server?

 

Yeah, read up on XSS. With JavaScript you have full control of the DOM, which means they can point forms (login?) to their own servers.

 

You can use htmlspecialchars to help prevent this.

[icydash]

What is a DOM?

 

What about areas on my website covered by .htpasswd instead of a form login?  I'm not sure how .htpasswd works -- does it leave a cookie on your computer or something?  If so, I guess someone could log in to the secure areas and then go to the forum that has the malicious code, and the malicious code could grab the cookie and send it to a website that logs the information.

 

Does anyone know how .htpasswd works?  Cookies? Sessions?

[gizmola]

What is a DOM?

 

DOM = Document Object Model.  When you write javascript code, typically it is so that you can manipulate the DOM.  Since javascript code runs on the client computer, it is exceedingly dangerous when your site allows people to store javascript code in your database.  If an attacker manages to embed their javascript code in a page, users who access that page, inadvertantly will run the attackers code, which looks to them like it came from your site.

 

 

What about areas on my website covered by .htpasswd instead of a form login?  I'm not sure how .htpasswd works -- does it leave a cookie on your computer or something?  If so, I guess someone could log in to the secure areas and then go to the forum that has the malicious code, and the malicious code could grab the cookie and send it to a website that logs the information.

 

Does anyone know how .htpasswd works?  Cookies? Sessions?

 

None of the above.  What you are talking about is HTTP Authentication.  When you secure a directory using this form of authentication, the server prompts the client for a name and password combination to a particular "Realm".  The .htpasswd file is simply a configuration detail.  There are a variety of different options available, depending on your server, for how the usernames and passwords will be evaluated, and how the passwords are stored, so that they can be checked.

 

Regardless of the format of the passwords, all forms of this authentication share the same mechanics.  The browser sends the credentials in an HTTP Header field name "authorization:".  Once you've authenticated with a realm, the browser continues to send this field (which is some form of the username and password at minimum) with every request.  The mechanism is very similar to how a session cookie works.

 

[icydash]

Thanks a lot for your explanation; everything makes a lot more sense now. 

 

As to HTTP Authentication, if every time a request is sent, the HTTP Header field name "authorization" has the login credentials, is there a way to maliciously run javascript code to swipe the credentials from the HTTP header of a victim visiting the page?  i.e. is there any way to swipe the credentials, if I can get full javascript access using the exploit?

 

I guess I'm trying to determine if this kind of an attack would be more of a nuisance attack (i.e. the attacker can use javascript to make 1000 popups which are annoying, or redirect the user to his/her own website) or if the attack can actually steal sensitive authentication information (i.e. some important cookie information that I don't know exists, or HTTP Authentication information).

 

Thanks again.

[Christian F.]

Why redirect the user, when you can make it appear as if the user is doing it him/herself? Remember that the server cannot tell the who made the request, just that it originates from the client's browser. Remember that anything you can do normally, a JS can emulate perfectly.

So, yes: It is way more than just a nuisance attack, even if the header data wasn't available.

[icydash]

I'm wondering if there's a way to do something like this:

 

<Script language=javascript>
var req = new XMLHttpRequest();
req.open('GET', document.location, false);
req.send(null);
var headers = req.getAllResponseHeaders().toLowerCase();
alert(headers);
</script>

 

...where it grabs the HTTP Authentication header, but I can't seem to get it to work.  The above code seems to have all the headers EXCEPT HTTP Auth.  If I can get that to work, then instead of an alert, I could have it send the headers to a log.php file on another server and my site would be exploited.

[gizmola]

Very good question.  For security reasons there isn't an equivalent "getAllRequestHeaders".  The security credentials are sent in the request to the server, and are not present in the response.

 

              Request (GET, POST, etc)

Client    ----->    Server

 

              Response

Client 

 

 

Needless to say, in an XMLHttpRequest, the entire point of the exercise is to get the response data back from the server, so they make the full range of headers available.

 

The more typical concern with Realms is that someone might sniff your traffic and have access to the credentials directly. 

 

Your exploit code is typical of an xss cookie exploit, where what gets sent to the server via ajax is the value of document.cookie

 

 

[icydash]

Thanks for your explanation -- I didn't realize the servers response didn't also carry the header information.  It makes sense that it didn't work, then.  I suppose the only real information you'd be able to steal, like you mentioned, is cookie information stored in document.cookie, which isn't a real problem for me because my site doesn't use cookies; rather, it uses HTTP Auth.

 

What if the server had the HTTP request TRACE activated (like POST, GET)?  Doesn't that basically return/echo whatever you send to it?  Could I then do an XMLHttpRequest() somehow and have the server bounce back the header information?  I think I've read about an attack like that before.  Also, how do I even figure out if I have TRACE enabled, haha?

 

Also, would it work if I create malicious code that opens an XMLHttpRequest() to a different server, one that I control, and have the server (using PHP) read the headers and grab the HTTP Auth info (this seems like it'd be a big security oversight if it did allow me to do this)?  Or does the browser only send the HTTP Auth header information to the original server, and not to others?

 

[Christian F.]

I must confess that I'm a bit concerned about your absolute focus on the HTTP headers, and lack of response to my posts. From what I've understood, it might seem as if you think that XSS wouldn't be much of a real security issue, if the HTTP auth header cannot be copied. If this is the case, then I'm afraid you're in the wrong.

There is really no need to steal the auth information from a session, since you can get the user's browser to do everything you'd want to do anyway. Making it appear as if the user, which only opened the page with the XSS attack, himself instigated these actions.

 

Let's say you had a link/form on the page which you could use to wipe the entire database, and the "login successful" page contained an XSS attack vector. All an attacker would need to do, is craft a JS that opened the page in a hidden div, fill out the required data, and resubmit it to the server. You wouldn't see this happening at all, as it would take only a few milliseconds, and the server sees a legit "delete all" request coming from your browser.

No information stolen, and no need to get to the headers.

 

As for your question: You can quite easily open a (hidden) iframe, and use the GET/POST method to send all of the headers (available to the JS) to the 3rd party server. In fact, this is probably the most common application for XSS attacks. So, no, you wouldn't get the HTTP Auth info, but there are plenty of ways around it. As demonstrated above.

[icydash]

ChristianF: thanks for your response.  Indeed, I had missed your earlier post.

 

I see the implications in being able to craft javascript so that the attacker could effectively make the victims browser do what he wants, like drop all the tables in a SQL database.  However, the reason I'm not focused on this is because I don't use a MySQL database or cookies for security.  The way I protect my content is a folder with HTTP Auth.  I give users that I want to be able to access my private data the username and password. 

 

So while I see the implications of what you're saying, being able to "control" the victims browser isn't as much of a concern for me; I'm more concerned about the accessibility/security of the private information stored in my "members" folder.

 

[gizmola]

icydash,

  HTTP Auth is a very poor level of authentication unless you're utilizing HTTPS.  For most people it's used on intranets or quick and dirty security with a limited number of users.

 

 

[icydash]

I only have a few users that I allow into my "members" area, and while I keep hearing that HTTP Auth is very poor security-wise because it sends the auth info in simply base64 encrypted form, it seems that it's actually one of the better methods of security for protecting limited content.  Things like Cookies and Sessions appear much more subject to attack, especially with XSS, and nobody seems to be able to find a way to grab the HTTP Auth info short of somehow getting in-between the server and client, which is a huge feat.

[gizmola]

I only have a few users that I allow into my "members" area, and while I keep hearing that HTTP Auth is very poor security-wise because it sends the auth info in simply base64 encrypted form, it seems that it's actually one of the better methods of security for protecting limited content.  Things like Cookies and Sessions appear much more subject to attack, especially with XSS, and nobody seems to be able to find a way to grab the HTTP Auth info short of somehow getting in-between the server and client, which is a huge feat.

 

It's really not better.  First off, anyone who accesses your site in a cafe over wifi will be an easy target.  This is equally a problem without HTTP Auth, but at least most competent session code will include some countermeasures against privilege escalation.  One your HTTP Auth is compromised it's game over.  HTTP Auth is basically wide open to brute force attacks. 

 

Secondly, if you have a small group of users, are you saying you don't trust them?  How exactly will these XSS attacks occur?  The small group of people you are talking about are actually not trustworthy?

 

You seem to want to convince yourself that HTTP Auth security is in some way advantageous. 

 

It's an option that I've used myself a few times, and you can implement it programatically in PHP, which allows you to use a database table for example, rather than an htpasswd file.  However, there should be no doubt that it is a quick and dirty somewhat antiquated system that exposes credentials repeatedly. 

 

Oh and did I mention that the only way you can clear the authentication is to close the browser? 

[fenway]

http auth is a very quick-and-dirty solution -- but it's not flexible enough.

[icydash]

gizmola, I think you misunderstood what I was saying.

 

For my particular situation, in which I have some content I'd like to protect but allow a small number of friends (like, less then 10) to access, HTTP Auth seems to be the best method.  If instead, for my login script, I used MySQL databases or sessions/cookies to authenticate my users on my site instead of HTTP Auth, my site would be a lot more vulnerable under these particular conditions.  If I happen to inadvertently write poor PHP code, it's not particularly difficult for a remote attacker to use MySQL injection or XSS/other attacks to grab login/session/cookie data from the server or an unsuspecting victim. 

 

Conversely, the only real way to get HTTP Auth information is to get the headers, which Javascript doesn't have access to.  Thus, the only real way to get the HTTP Auth info is really to get between the server and the client somehow.  And while your "sitting in a cafe" scenario may work for a HUGE site like Facebook, which millions of people visit daily, I HIGHLY doubt there will be many people sitting in a cafe, where an attacker just happens to be, going to my members area and logging in through which that attacker could steal the credentials.  Given the limited number of members, it seems highly improbable an attacker would find a way to get between the server and the client to grab the HTTP Auth headers/credentials.

 

As to your brute force comment, there are now a lot of scripts to prevent brute forcing of HTTP Auth, especially if you're using HTTP Auth through PHP.

[gizmola]

A couple of clarifications --

 

All we are talking about is the method of authentication you are using to secure a section of your site.  MySQL and php sessions have nothing to do with Authentication.  We could compare and contrast mysql vs an htpasswd file and in many ways, using a mysql table will be superior, from the ability to have a simple custom status, to administration of the users, to the fact that your users won't even be able to update their own passwords.  I realize it's not an apples/oranges comparison, and as I also mentioned it's possible to use HTTP auth AND utilize a mysql based user table. 

 

The main thing the HTTP Auth buys you is:

 

-Built into the browser

-No need to create your own auth form

-In fact you can avoid any code whatsoever

 

We can all agree that is the case, and for a quick and dirty security system, most of us have used it at one time or another.

 

And while your "sitting in a cafe" scenario may work for a HUGE site like Facebook, which millions of people visit daily, I HIGHLY doubt there will be many people sitting in a cafe, where an attacker just happens to be, going to my members area and logging in through which that attacker could steal the credentials.  Given the limited number of members, it seems highly improbable an attacker would find a way to get between the server and the client to grab the HTTP Auth headers/credentials.

 

Actually it just takes one person.  As for what is reasonably expected to happen or not, that is anyone's guess, but the simple fact of the matter is that it only takes one "trusted" person to use your site on wifi with someone sniffing, and they will be in.  I don't think this is likely, however, I also don't think it's likely that someone is going to target your site for XSS exploitation either.  They are equally unlikely scenarios, so what I'm really focused on, is the way you seem to be trying to make an argument in this thread that HTTP Auth is superior to a traditional PHP form based authentication script, that most likely uses php sessions. 

 

At the risk of repeating myself, what is also a significant weakness of HTTP Auth is that as long as the browser stays open the authentication is current.  So if someone authenticates to your trusted area, anyone else who happens to use that browser will also be authenticated.  You have no visibility into the authentication process since it entirely occurs between the browser and server, and you can't timeout or take any countermeasures against intrusion. 

 

I also was trying to make the point, that XSS has to have an exploit vector.  If you are not allowing user content from people on your site, or if you are, however you have taken the necessary countermeasures, you don't need to worry about XSS.  Your entire premise seems to be that XSS is highly likely, and thus XSS is your biggest worry, and your argument proceeds from there.

 

In conclusion, I have nothing against HTTP Auth, and we've explored it a great deal in this thread, which may be useful to future developers.  In your scenario, it seems like a reasonable time saving measure, although having used it myself, it has a high administration cost, in your having to setup users and communicate their passwords to them. 

 

Here's some skeleton code that could be used to authenticate a site, using HTTP Auth in PHP script form, which I alluded to previously. 

 

if (isset($_SERVER['PHP_AUTH_USER']) AND isset($_SERVER['PHP_AUTH_PW'])) {
$valid = 0;
$user = mysql_real_escape_string($_SERVER['PHP_AUTH_USER']);
$password = sha1($_SERVER['PHP_AUTH_PW']);
// Query database here for user/pw combination
// $valid = result of SELECT count(*) .. FROM TABLE WHERE user = $user AND pwd = $password ...

if ($valid !== 1) {
	header('WWW-Authenticate: Basic realm="Your Site Login"');
	header('HTTP/1.0 401 Unauthorized');
	unset($_SERVER['PHP_AUTH_USER']);
	unset($_SERVER['PHP_AUTH_PW']);
	exit;
}	
} else {
header('WWW-Authenticate: Basic realm="Your Site Login"');
   	header('HTTP/1.0 401 Unauthorized');
   	unset($_SERVER['PHP_AUTH_USER']);
   	unset($_SERVER['PHP_AUTH_PW']);
   	exit;	
}

 

 

[icydash]

Thanks a lot for your comments.

 

I think we had a really great discussion here of a lot of interesting issues.  I hope future developers find this thread useful, and I thank everyone for their comments.

[Christian F.]

You're most welcome, at least from my side.

I too hope this thread will be found quite useful and informative, that's what we're here for after all.