Security issues Unit 27 Web Server Scripting Extended Diploma in ICT 2016 Lecture: Phil Smith
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=pu ppy 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 we did some of this See http://php.net/manual/en/function.htmlen tities.php http://www.php.net/manual/en/security.database. sql-injection.php
Summary We have learned several problem with web site/page security and their potential solutions.