Security issues
Unit 27 Web Server Scripting
Extended Diploma in ICT
Criteria D3
• D3 Recommend ways to improve web security when
using web server scripting
•
•
•
•
•
•
Clean browser input
Don’t put everything in the web directory on the server
Use POST instead of GET
Validate on the server
Specify the mode when opening a file
Log suspicious errors
Clean browser input
• The problem:
• Input containing special characters such as ! and
& could cause the web server to execute an
operating system command or have other
unexpected behaviour
• User input stored on the server, such as
comments posted to a web discussion program,
could contain malicious HTML tags and scripts.
When another user views the input, that user's
web browser could execute the HTML and scripts.
Clean browser input
• The solution:
• never trust any input from a browser.
• strip unwanted characters, invisible characters
and HTML tags from user input
Example
<?php
if(!filter_has_var(INPUT_POST, "url"))
{
echo("Input type does not exist");
}
else
{
$url = filter_input(INPUT_POST,
"url", FILTER_SANITIZE_URL);
}
?>
•
•
•
Check if the "url" input of the "POST" type exists
If the input variable exists, sanitise (take away invalid characters) and store
it in the $url variable
http://www.W3ååSchøøools.com/ becomes http://www.W3Schools.com/
Don’t put everything in the
html directory on the server
• The problem
• Every file in the HTML directory can be accessed
by a web browser if the URL is known
• If you had a file called dbconnect.php that
contained the login details for the database, the
name could be easily guessed and then a hacker
could navigate directly to it
• The solution
• Put all data files in a directory outside the
html directory or its subfolders
Use POST instead of GET
• The problem
• GET sends all form input to the web application as
part of the URL
• If this is a user name or password it can be read
• http://www.example.com/cgibin/cart.cgi?username=jsmith&password=puppy
• The solution
• POST method sends form input in a data stream
• The data is not visible in the browser location window
and is not recorded in web server log files
Validate on the server
• A hacker can
• save an HTML form,
• disable the embedded Javascript which does
validation
• use the modified form to submit bad data back to
the web application.
• the application expects all input validation to
have already been done by the web browser
and therefore doesn't double check the input
Validate on the server
• The solution
• Make sure the server script validates all input
• This example checks for a valid integer
<?php
$int = 123;
if(!filter_var($int, FILTER_VALIDATE_INT))
{
echo("Integer is not valid");
}
else
{
echo("Integer is valid");
}
?>
Specify the mode when
opening a file
• The problem
• If a file, such as a configuration file, is opened, the
defaults may be read/write
• This leaves the file vulnerable to malicious
updates
• The solution
• Explicitly open the file with a specified mode, such
as read-only
Log suspicious errors
• The problem
• web applications are frequently attacked by
hackers
• Without error logging, you may not know you are
being attacked
• The solution
• trap and recover from errors, but also log events
that may indicate an attack
Log suspicious errors
• Evidence of attack
• attempts to access a non-existent file or one the
browser doesn't have privileges to read
• Detect if a form is submitted with GET instead of
POST
• Forms submitted without required fields (hacker may
be using a false copy of the form)
• Input with “..” suggests an attacker is trying to access
files with a relative path
• Requests from multiple IP addresses suggest a denial
of service attack
Further reading
• cross-site scripting
• SQL injection