protecting against SQL database INJECTION and Cross-Scripting
It is possible for a hacker to enter the following seemingly innocuous text into the UserName textbox to gain entry to the system without having to know a valid user name and password:
‘ Or 1=1 —
The hacker breaks into the system by injecting malformed SQL into the query. This particular hack works because the executed query is formed by the concatenation of a fixed string and values entered by the user, as shown here:
In the case of the user entering a valid user name of “Paul” and a password of “password”, strQry becomes:
SELECT Count(*) FROM Users WHERE UserName=’Paul’ AND Password=’password’
But when the hacker enters ‘ Or 1=1 —
the query now becomes:
SELECT Count(*) FROM Users WHERE UserName=” Or 1=1 –‘ AND Password=”
Because a pair of hyphens designate the beginning of a comment in SQL, the query becomes simply:
SELECT Count(*) FROM Users WHERE UserName=” Or 1=1
The expression 1=1 is always true for every row in the table, and a true expression or’d with another expression will always return true. So, assuming there’s at least one row in the Users table, this SQL will always return a nonzero count of records.
Enter Bad Guy who, instead of typing his name, types the following in the input field:
< script language='javascript' >alert
(‘gotcha!’);< /script>
Such a scenario becomes very dangerous when a Website accepts [comments on a blog] content from one user and displays it to others as well. (The code above is rather usable for “self-hacking.”) Typical examples are Web-based message boards or community sites. The injected script could perform unwanted actions on the client or send information to external sites.
There are other ways to inject script, such as within an HTML tag.
< a href=" [event]='bad script here' ">
click me < /a>
The script can even be hosted on another Web server (anonymous hosting companies or previously compromised servers being an excellent choice). In this case, the malicious string would contain links to the real script. An example below, illustrating an alternative way of submitting malicious content via cookies:
If the dynamic content comes from a cookie (example taken from the Microsoft advisory),
< % Response.Write(""); %>
the cookie can be trivially manipulated on the client side to:
Cookie: %22+onload%3D%27window%2Elocation%3D
%22http%3A%2F%2Fwww%2Eevilsite%2Ecom%22%3B%27
which would lead to
redirecting the user to another site.
What to do? There are a number of ways of dealing with this issue. The core idea is to encode the user-input information in such a way that it will be displayed the same as the user input, but stored and transmitted in a form that will prevent the vulnerability from being exploited.
The solution is offered by what is called HTML encoding, using special character sequences.
Remote File Inclusion (RFI), Local File Inclusion (LFI)
The following PHP functions – using variables instead of hard-coded names:
include($variable);
require($variable);
include_once($variable);
require_once($variable);
can be tricked into fetching a malicious script from a remote server and running it as part of the currently executing script, if the value of $variable came from an HTTP query string or any other user-supplied input
The attacking script can upload files, replacing yours, execute commands, display your entire database, delete it, and perform directory listings … etc.! There are two options in the php.ini file that can be set to prevent this from happening:
allow_url_fopen = Off
allow_url_include = Off
For more php.ini security settings, see Networking –> Internet, Web Site, Security.
Safe Mode
PHP’s Safe Mode provides a similar functionality compared to “disable_functions”. When you enable “safe_mode”, PHP restricts specific functions and certain types of functionality that could be deemed a security threat. However, there are many ways around these restrictions, as demonstrated in an article by HD Moore titled “PHP Safe Mode Considered Harmful”. “Safe Mode” is so bad that it will not be included in PHP version 6.0. The fact that the PHP developers themselves realized this was not an effective security measure should raise a red flag. By default, safe_mode is off. Leave it that way.
Disable Functions
PHP contains several functions that are known to be vulnerable to command injection attacks. You can add the following line to your php.ini file to prevent these functions from executing (they can still be called, but the calling application will receive an error):
in php.ini:
disable_functions = exec, passthru, shell_exec, system, proc_open, popen, curl_exec, curl_multi_exec, parse_ini_file, show_source
With these functions disabled there is a chance that some applications may no longer function correctly. Before implementing this defensive measure I ran the following command on my server to see if any of my applications were in fact using these functions:
egrep -r ‘(exec| passthru| shell_exec| system| proc_open| popen| curl_exec| curl_multi_exec| parse_ini_file| show_source)’ *.php
all I got was “* Runs just before PHP shuts down execution.” in a comment in 1 program. No problem.
(the word execution starts with ‘exec’ which was the very first string that it looked for)