PHP URL switch exploit?

[vbcoach]

Hello all.

 

I have a sports website that looks up team/league-specific information based upon the team or league id. This information is presented by url by using a switch in the url. For example: www.widget.com/changeme.php?x=123

 

As you all probably know, this opens my site to a huge security rick and potential exploit. Is there anyway to hide or otherwise adjust this url so it doesn't display this switch? Any other thoughts on how I could do this securely?

 

Thanks in advance for your help.

[Ch0cu3r]

 

 

anyway to hide or otherwise adjust this url so it doesn't display this switch

 

No, you can obfuscate it by using using mod_rewrite, eg have urls like  site.com/page/123 but it does not make it any securer.

 

 

Any other thoughts on how I could do this securely?

 

Yes make sure you are always validate and sanitizing the user input before using it. Such as if you expecting a number, then make sure you check that it is a number and then use intval to sanitize the number etc.

 

All exploits are caused by simply not doing this. You are simply leaving the door wide open to all sorts of attacks if you don't do this properply. Helpful read

http://www.phptherightway.com/#data_filtering

[Jacques1]

Hi,

 

you're talking in riddles.

 

What's “a switch in the URL”? You mean the x parameter? How is that a security risk?

[vbcoach]

 

No, you can obfuscate it by using using mod_rewrite, eg have urls like  site.com/page/123 but it does not make it any securer.

 

 

Yes make sure you are always validate and sanitizing the user input before using it. Such as if you expecting a number, then make sure you check that it is a number and then use intval to sanitize the number etc.

 

All exploits are caused by simply not doing this. You are simply leaving the door wide open to all sorts of attacks if you don't do this properply. Helpful read

http://www.phptherightway.com/#data_filtering

 

Way over my head.  Can you simplify this for me?

[vbcoach]

Hi,

 

you're talking in riddles.

 

What's “a switch in the URL”? You mean the x parameter? How is that a security risk?

Had a programmer see that if he copied the URL and changed the ?X=123 to "anyting" like the letter "A", it reported errors about the website and gives potential hackers all the information they need to take advantage of that exploit.

[Jacques1]

A URL parameter itself is just a piece of data coming from the client. It isn't any more dangerous than a form entry or a cookie or whatever.

 

Trouble begins when programmers fail to process the data properly. For example, if you insert the raw value into an SQL query, attackers can use this to manipulate the query. And if you insert the value directly into your HTML document, this can be used to inject malicious JavaScript code.

 

It's very important to understand that this is not a problem of the data itself or how the data is passed to your server. The client may send any data they want in any way they want. It's your responsibility to make sure your application doesn't do funky stuff with it.

 

Proper handling of data always depends on the specific context. There is no “one-size-fits-all” solution. Preparing data for an SQL query is an entirely different thing than preparing it for an HTML context. If you want us to help you, you need to show us the exact context. Do you want to use the parameter in a query? The HTML document? Somewhere else?

 

For a start, you might wanna read this introduction.

[cyberRobot]

Assuming that the GET variable (x) is always a number, you can run a simple test before using the value.

<?php
//IF AN ID WAS PASSED --AND-- IT'S A NUMBER
if(isset($_GET['x']) && ctype_digit((string)$_GET['x'])) {
     //RUN CODE TO PROCESS x
 
//ELSE...LET USER KNOW THE ID IS INVALID
} else {
     //ERROR MESSAGE HERE
}
?>

 

More information about ctype_digit() can be found here:

http://www.php.net/manual/en/function.ctype-digit.php

Edited April 16, 2014 by cyberRobot

[vbcoach]

 

Assuming that the GET variable (x) is always a number, you can run a simple test before using the value.

<?php
//IF AN ID WAS PASSED --AND-- IT'S A NUMBER
if(isset($_GET['x']) && ctype_digit((string)$_GET['x'])) {
     //RUN CODE TO PROCESS x
 
//ELSE...LET USER KNOW THE ID IS INVALID
} else {
     //ERROR MESSAGE HERE
}
?>

 

More information about ctype_digit() can be found here:

http://www.php.net/manual/en/function.ctype-digit.php

 

 

Now that's what I am talking about guys (and gals)  Thanks for the explanations!!!

[Jacques1]

Wrong, wrong, wrong.

 

It hate being the party pooper, but input validation has absolutely nothing to do with security. When you think it does, you're committing two fallacies at the same time:

 

• You mistake injection vulnerabilities for input problems. They're not.
• You try to apply a “one-size-fits-all” approach, which never ends well.

 

Things like SQL injections or cross-site scripting are not an input problem. They're not caused by the user giving you “wrong input”. Let me try something:

DROP TABLE phpfreaks.users;

Did I just kill PHP Freaks? No. This “dangerous query” does absolutely nothing. It's a harmless piece of text in a forum.

 

However, it would cause trouble if the application actually executed this query. So SQL injections are in fact an interpretation problem. They happen when the application misinterprets data as executable code and runs it.

 

This is really important to understand: Injections vulnerabilities are not an input problem. You cannot prevent them through validation, filtering or whatever, no matter how hard you try. You need to make sure that the data actually gets interpreted as data and never as code. This is usually done through escaping.

 

Secondly, abusing validation as a security feature is a “one-size-fits-all” attempt. Sure, a number probably doesn't do any harm in any context. But what about, say, an e-mail address? Is that dangerous? In some contexts, yes! E-mail addresses are allowed to contain single quotes, so they may very well be used for an SQL injection.

 

As I already said above, preparing data is always context-dependent. You can't just run them through some validator and be happy. This doesn't work. You have to prepare the data for the specific context. If you want to include it in an SQL query, you need a prepared statement or SQL-escaping. If you want to include them in an HTML document, you need HTML-escaping. And if you want to put them into a JavaScript context, you need yet another strategy.

 

I know, this is a bit more complicated than calling some silly number validator. But this is reality. Nobody said programming is easy.

Edited April 16, 2014 by Jacques1