Data Validation Data Validation n Objective To ensure
Data Validation
Data Validation n Objective : To ensure that the application is robust against all forms of input data, whether obtained from the user, infrastructure, external entities or database systems. 2
Data Validation The most common web application security weakness is the failure to properly validate input from the client or environment. This weakness leads to almost all of the major vulnerabilities in applications, such as XSS, SQL Injection n Data from the client should never be trusted for the client has every possibility to tamper with the data. n 3
Data Validation n Data Validation Strategies : There are four strategies for validating data, and they should be used in this order: Accept known good n Reject known bad n Sanitize with Whitelist n Sanitize with Blacklist n 4
1. Accept known good n n This strategy is also known as "whitelist" or "positive" validation. The idea is that you should check that the data is one of a set of tightly constrained known good values. Any data that doesn't match should be rejected. Data should be: n Strongly typed at all times n Length checked and fields length minimized n Range checked if a numeric n Unsigned unless required to be signed n Syntax or grammar should be checked prior to first use or inspection If you expect a postcode, validate for a postcode (type, length and syntax) 5
2. Reject known bad n n This strategy, also known as "negative" or "blacklist" validation is a weak alternative to positive validation. Essentially, if you don't expect to see characters such as %3 f or Java. Script or similar, reject strings containing them. This is a dangerous strategy, because the set of possible bad data is potentially infinite. Adopting this strategy means that you will have to maintain the list of "known bad" characters and patterns forever, and you will by definition have incomplete protection. 6
3. Sanitize with Whitelist n n Any characters which are not part of an approved list can be removed, encoded or replaced. Here are some examples: If you expect a phone number, you can strip out all nondigit characters. Thus, "(555)123 -1234“ or "555. 1234“. All can be converted to 5551231234. Note that you should proceed to validate the resulting numbers as well. As you see, this is not only beneficial for security, but it also allows you to accept and use a wider range of valid user input. 7
4. Sanitize with Blacklist n n Eliminate or translate characters (such as to HTML entities or to remove quotes) in an effort to make the input "safe". Eg. , <b> 8
PHP & Security n PHP keeps on growing as a language, making headway into enterprise and corporate markets. n Consequently PHP applications often end up working with sensitive data. Unauthorized access to this data is unacceptable. Security n To prevent problems a secure design is n 9
Input Validation n One of the key concepts you must accept is that user input is unreliable and not to be trusted. n n n Partially lost in transmission between server & client. Corrupted by some in-between process. Modified by the user in an unexpected manner. Intentional attempt to gain unauthorized access or to crash the application. Which is why it is absolutely essential to validate any user input before use. Security 10
Accessing Input Data n As of PHP 4. 1, there a series of superglobals that offer very simple access to the input data. n n n n $_GET – data from get requests. $_POST – post request data. $_COOKIE – cookie information. $_FILES – uploaded file data. $_SERVER – server data $_ENV – environment variables $_REQUEST – combination of GET/POST/COOKIE Security 11
Register Globals n Arguably the most common source of vulnerabilities in PHP applications. n Any input parameters are translated to variables. n ? foo=bar n >> $foo = “bar”; No way to determine the input source. n Prioritized sources like cookies can overwrite GET values. n Un-initialized variables can be “injected” via user inputs. Security 12
Register Globals if (authenticated_user()) { $authorized = true; } if ($authorized) { include '/highly/sensitive/data. php'; } n Because $authorized is left un-initialized if user authentication fails, an attacker could access privileged data by simply passing the value via GET. http: //example. com/script. php? authorized=1 Security 13
Solutions To Register Globals n Disable register_globals in PHP. ini. n n Already done by default as of PHP 4. 2. 0 Code with error_reporting set to E_ALL. n Allows you to see warnings about the use of un-initialized variables. Security 14
Validating Strings PHP comes with a ctype, extension that offers a very quick mechanism for validating string if content. (!ctype_alnum($_GET['login'])) { n echo "Only A-Za-z 0 -9 are allowed. "; } if (!ctype_alpha($_GET['captcha'])) { echo "Only A-Za-z are allowed. "; } if (!ctype_xdigit($_GET['color'])) { echo "Only hexadecimal values are allowed"; } Security 15
XSS n Cross Site Scripting (XSS) is a situation where by attacker injects HTML code, which is then displayed on the page without further validation. Can lead to embarrassment. n Session take-over. n Password theft. n User tracking by 3 rd parties. n Security 16
Preventing XSS n Prevention of XSS is as simple as filtering input data via one of the following: n htmlspecialchars() n Encodes ‘, “, <, >, & n Eg (& (ampersand) becomes & ) n htmlentities() n Convert anything that there is HTML entity for. n Eg (  => newline ; %amp => &) n strip_tags() n Strips anything that resembles HTML tag. n echo strip_tags("Hello <b>world!</b>"); n Security Output (Hello world!) 17
Preventing XSS $str = strip_tags($_POST['message']); // encode any foreign & special chars $str = htmlentities($str); // maintain new lines, by converting them to echo nl 2 br($str); // strip tags can be told to "keep" certain tags $str = strip_tags($_POST['message'], '<b><p><i><u>'); $str = htmlentities($str); echo nl 2 br($str); n Tag allowances in strip_tags() are dangerous, because attributes of those tags are not being validated in any way. Security 18
Tag Allowance Problems <b style="font-size: 500 px"> TAKE UP ENTIRE SCREEN </b> <u onmouseover="alert('Java. Script is allowed'); "> <b style="font-size: 500 px">Lot's of text</b> </u> <p style="background: url(http: //tracker. com/image. gif)"> Let's track users </p> Security 19
SQL Injection n SQL injection is similar to XSS, in the fact that not validated data is being used. But in this case this data is passed to the database. n Arbitrary query execution n Removal of data. n Modification of existing values. n Denial of service. n Arbitrary data injection. Security 20
SQL Escaping n If database interface extension offers dedicated escaping functions, USE THEM! n My. SQL n mysql_escape_string() n mysql_real_escape_string() n Postgre. SQL n pg_escape_string() n pg_escape_bytea() n SQLite n sqlite_escape_string() Security 21
Solution DO NOT PLACE USER INPUT INTO EXECUTABLE STATEMENTS!! Security 22
Error Reporting n By default PHP will print all errors to screen, startling your users and in some cases disclosing privileged information. File paths. n Un-initialized variables. n Sensitive function arguments such as passwords. n n At the same time, disabling error reporting would make bug tracking near impossible. Security 23
Solution? n This problem can be solved by disabling displaying of error messages to screen ini_set(“display_errors”, FALSE); n And enabling logging of errors ini_set(“log_errors”, TRUE); n to a file ini_set(“error_log”, “/var/log/php. log”); n or to system central error tracking facility ini_set(“error_log”, “syslog”); Security 24
Session Security n Sessions are a common tool for user tracking across a web site. n For the duration of a visit, the session is effectively the user’s identity. n If an active session can be obtained by 3 rd party, it can assume the identify of the user who’s session was compromised. Security 25
Session Fixation n Session fixation is an attack designed to hard-code the session id to a known value. n If successful the attack simply sends the known session id and assumes the identity of the victim. Security 26
Exploit n A most common form of an exploit involves having the user click on a link that has a session id embedded into it. <a href= “http: //php. net/manual/? PHPSESSID=hackme”> PHP. net Manual</a> n If the user does no have an existing session their session id will be “hackme”. Security 27
Securing Against Session Fixation n To avoid this problem you should regenerate the session id on any privilege (Ex. Login) change. <? php session_start(); // some login code if ($login_ok) { // user logging in session_regenerate_id(); // make new session id } ? > Security 28
Shared Hosting Most PHP applications run in shared environments where all users “share” the same web server instances. n This means that all files that are involved in serving content must be accessible to the web server (world readable). n Consequently it means that any user could read the content of files of all other users. n Security 29
The PHP Solution n PHP’s solution to this problem are 2 INI directives. n open_basedir – limits file access to one or more specified directories. n Relatively Efficient. n Uncomplicated. n safe_mode – limits file access based on uid/gid of running script and file to be accessed. n Slow and complex approach. n Can be bypassed with little effort. Security 30
Questions Security 31
- Slides: 31