Web Security CS th November , Jonathan Francis Roscoe, Department of Computer Science, Aberystwyth University

Transcription

1 Web Security CS th November 2012

2 Session Errors Some people are having errors creating sessions: Warning: session_start() [function.session-start]: open(/var/php_sessions/sess_d7hag76hgsfh2bjuhmdamb974, O_RDWR) failed: Permission denied (13) in /berw/homes1/j/jjr6/public_html/index.php on line 2 I think this is due to configuration problems on the IS server, however, a simple work around is to create your own location for session files: $ mkdir ~/php_sessions $ chmod -R 700 ~/php_sessions Then specify this before you call session_start(): <?php session_save_path(trim(`echo ~`).'/php_sessions'); session_start();?>

3 Aberystwyth Guild ImageShack Google (Blogger) Symantec AVG Microsoft Notable Examples

4 Some Terminology Cross-Site Scripting (XSS) is the injection of client-side code into web applications; victims may be using a trusted website but sending data to another. SQL Injection concerns manipulating web forms that interact with databases so that arbitrary commands are executed. Cross-site request forgery involves forged requests sent from a user to a trusted website. Phishing usually concerns fake sites that mimic legitimate ones victims are often deceived into divulging data through what they think is a legitimate website.

5 Motivation Attacks on websites may occur for several reasons, including: Monetary gain Malicious intent Greyhat hacking Victim websites might be selected specifically, though more likely they are chosen as they run known vulnerable software. Many attacks are entirely automated, intended to manipulate search engine ranks and increase traffic flows to advertising.

6 Finding Victim Sites Typically, responsible bug finders will report bugs and they are documented on sites like SecurityFocus (formerly BugTraq). But this is a double edged sword. Proof of concepts, discussion, etc are provided for each documented exploit. Previously unknown exploits now become public knowledge; sometimes even before vendors are able to provide fixes. The general argument is that this encourages vendor response, rather than risk unknown exploits in the wild.

7 Server Administration Even as a web developer it helps to be aware of general administration issues. Larger companies may have a dedicated or outsourced administration team, but you should still make an effort to ensure you're aware what versions of Apache, PHP, etc the live system runs. Access to logs can be invaluable in debugging error reports. Don't allow error messages to be printed on a live server it may reveal code or database information.

8 Special Variables in PHP PHP has a number of special variables that either provide information about the environment, or from the client. $_GET an associative (named element) array that contains variables passed to it in the url (e.g. search.php?q=xbox) $_POST similar to $_GET but contains variables passed in a HTTP POST request The information in $_GET and $_POST is unprocessed and potentially contains malicious data, so you should avoid using it before sanitisation. $_SESSION contains the variables stored in your session whilst $_SERVER and $_ENV provide general server/environmental information.

9 Authentication & Authorisation Authentication concerns verifying that the user is who they claim to be. In essence, checking their username and password match. Authorisation is checking that an authenticated user is allowed to do something they are allowed to do. For example, deleting users should only be possible by administrators.

10 Sanitisation & Validation User input is where the most common security vulnerabilities occurs. $username = filter_var($_get['username'], FILTER_SANITIZE_STRING, FILTER_FLAG_STRIP_HIGH); $sql = "SELECT * FROM users WHERE username='$username';"; Without filters, it would be possible to modify the username variable to execute arbitrary commands.

11 Validation Validation is about checking to see if data matches an expected format. For example, we would expect an address to have symbol in it; but not characters like & or ^. is a great site that provides user-contributed regular expressions for common validation requirements. A simple example: ^\w+@[a-za-z_]+?\.[a-za-z]{2,3}$

12 Sanitisation Sanitisation refers to making user input safe for processing. You've probably seen or implemented some form of client-side security- such as a Javascript popup if you don't complete a form properly. These mainly exist to be quick and look pretty, they are not at all secure. So you must sanitise input on the server-side. $username = filter_var (FILTER_SANITIZE_STRING, $_POST['username'] ) ; Regular expressions can be used to go beyond simply removing harmful characters and can validate specific requirements: if (preg_match ("/^http/", $_POST['url'])) echo "Got a URL! " ; else echo "URL is no good. ;

13 A Potential SQL Injection Another example, to demonstrate how devastating poor sanitisation and validation can be: mysql_query("select * FROM users WHERE password ='".$_POST['password']."'); What if the input was something like: '; DROP users--

14 Sanitisation and Validation in PHP Validation examples: preg_match() - returns a boolean based on regular expressions filter_var() - returns a boolean value based on inbuilt constant parameters such as FILTER_VALIDATE_ These don't modify the input, just tells us if it matches expectations. For sanitisation we can use: mysql_real_escape_string(), pg_escape_string() - escapes characters to make the string safe for SQL strip_tags() - will remove HTML and PHP from a string There are a variety of other functions and techniques you can use..

15 Don't trust the user! Anything sent from the client cookies, GET & POST requests can be easily manipulated by modifying the HTML or URL, so don't rely on them. For example, variables relating to authentication should be saved in the session, which is kept on the server, rather than on the client. Client-side measures can be aesthetic and useful, but are not secure. So always ensure you correctly process any information from the client first.

16 Shared Hosting A common and cheap solution for relatively low load websites is shared hosting systems; where many users have their own web directory and hostname on a single server. is a good example of this. The downside to such a system is an increase in risk. In a typical LAMP scenario PHP scripts are executed by a single user; though in more secure scenarios they are executed by the owning user. If a single user's script is exploited, many more websites and related systems could also be compromised. Fortunately there are ways around this.

17 Server- Side Analysis We mentioned static code analysis in the last session. Shared web hosting servers run code analysis tools regular so that vulnerable scripts can be identified and neutralised appropriately. Pixy is one such tool used by IS.. Dear Jonathan, Please disable your "PHP-Shell" program as soon as possible. At the moment, what you have basically allows anyone in the world to remove the entire contents of your account! (if they enter "rm -r /aber/jjr6/." as the command). Cheers, Alun.

18 Behind the Web Servers If a user can compromise a web host, this could lead to further exploitation of enterprise systems. For example, a PHP vulnerability may allow malicious users to execute arbitrary commands, for example, gaining root access. From there it may be possible to obtain ssh keys, hijack user accounts, access internal servers, etc.

19 Some Security Analysis Tools - Skipfish is an open source web application security scanner from Google - a generic vulnerability scanner modules exist to test off-the-shelf software (wordpress, drupal, etc) - Nikto2 for web server analysis - a free static code scanner for PHP

20 Environments Bugs in new code will have a serious impact on usability and security. A common technique for releasing code is to develop on isolated systems, then gradually deploy them in a limited or beta form, before going live. There are four typical environments referred to: Development - Usually the programmer's local machine. May use specialist data sets. Incomplete/untested functionality. Full debugging and error output. Testing - A local network server. Provides common test data for all developers. All code should have been partially tested and obtained from development branch of version control. Full debugging and error output.

21 Environments Staging/Pre-Production - A live server with limited accessibility. May be available to beta users. Should be treated as the live system. All code should have been fully tested and taken form stable branch of version control. Production - The live server. Code on this server should not be edited directly. System should be updated through some form of scheduled deployment procedure. Debugging information printed here is a security risk and unpleasant to end users - errors should be caught and politely reported.

22 Overview Ensure user is authenticated & authorised as appropriate Validate and sanitise all user input Avoid careless debugging/error reporting (configure php.ini not to print error messages on a live system) Development data (test files, svn metadata) should be removed Set permissions appropriately, especially on shared systems Utilise security software that can isolate holes in your application Don't develop on a live system develop in isolation

23 Further Reading Tutorial on security in PHP Google Talk: How to break web software Backtrack, a live linux distribution specifically for security testing Hack this site a training ground with various challenges Another website with various security challenges SecurityFocus formerly the BugTraq mailing list - Remote load testing (Are your database queries efficient enough?!) OWASP a community with a variety of material relating to web security Sanitisation in PHP Validation in PHP Some stats on web vulnerabilities Web application auditing website Tool for website vulnerabilities