Security issues

1. Security issues Unit 27 Web Server Scripting Extended Diploma in ICT

2. 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

3. 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.

4. Clean browser input • The solution: • never trust any input from a browser. • strip unwanted characters, invisible characters and HTML tags from user input

5. Example <?phpif(!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 $urlvariable • http://www.W3ååSchøøools.com/ becomes http://www.W3Schools.com/

6. 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

7. 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/cgi-bin/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

8. 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

9. 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");  }?>

10. 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

11. 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

12. 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

13. Further reading • cross-site scripting • SQL injection