|
Scripting
Security
|
 |
Whether
you program your form handlers and other web site programs
(scripts) in PHP, ASP, ASP.NET, PERL, or JAVA, you need
to be aware of potential security holes present in these
languages.
These security holes aren't necessarily flaws in the languages themselves,
they're more the result of poor programming practice by web site designers.
|
Below
are some common potential scripting and scripting language
security flaws and instructions on correcting them. The sample
code is written in PHP, but the theory applies to all scripting
languages.
INCLUDE FILES WITH .INC EXTENSION
If you use include files in your applications with an .inc extension (file.inc),
your script will be viewable by anyone who types the correct url into their browser.
SOLUTION
Use .asp or .php extensions instead. You'll get the same functionality as using
.inc but your script code will not be viewable.
ERROR HANDLING
Servers typically output error messages directly to the browser. This is helpful
when debugging your code, but could give a malicious user insight into your server
file structure.
SOLUTION
Suppress errors (don't display them in the browser) and instead send them to
the server error log.
In php, you would add the following code to your .htaccess file:
php_value display_errors 0
php_value log_errors 1
or set these values directly from your script:
ini_set("display_errors", 0);
ini_set("log_errors", 1);
UNVALIDATED PARAMETERS
When many sites implement user log in, a simple check like the one below is made
before displaying sensitive information:
if ($password == "valid_password")
$valid = 1;
if ($valid == 1)
echo "Display sensitive information";
Unfortunately, the $valid flag is set outside any control structure and can easily
be set from the url like so:
http://www.yoursite.com/secure_page.php?valid=1
This would allow access no matter what password was entered because the password
check lets the value set in the url through regardless of the password entered.
SOLUTION
Validate any log in flags like so:
if (isset($password))
{
if ($password == "valid_password")
$valid = 1;
else
$valid = 0;
}
else
$valid = 0;
if ($valid == 1)
echo "Display sensitive information";
Now, if the password isn't correct, the $valid flag will be set to 0 -
even if a malicious user tries to force set it from the url.
REGISTER GLOBALS
Specific to PHP, register_globals allows variables to be used without declaration.
For instance, in the above example the $password value was likely received from
a log in form but there's no way of telling that from the script.
I could just as easily have set the value for $password like I set the value
for $valid by using the url:
http://www.yoursite.com/secure_page.php?password=12345
Now this wouldn't really accomplish anything, but it does leave a huge security
hole if users can indiscriminately change your variable values by using the url.
SOLUTION
Turn register globals on in your .htaccess file:
php_value register_globals 1
or set the value directly from your script:
ini_set("register_globals", 1);
Now you have to access
your variables using the superglobal arrays. Instead of $password, you'll
use $_POST['password'] and for url encoded variables you'll use $_GET['value'].
|
More
Resources
|
If
you're programming in PHP, these simple fixes will secure
your scripts from all but the most sophisticated attacks.
|
For
specific code to apply these fixes to your scripts if you're
using another scripting language, do a web search for 'asp
security', 'perl
security', 'java
security', etc.
The forums at DevShed are
also a great resource for script security information. |
Next:
Database Security >
|
