PHP Security
Upcoming SlideShare
Loading in...5

PHP Security



PHP Security

PHP Security



Total Views
Views on SlideShare
Embed Views



3 Embeds 308 160
http://sopra.localhost 144 4



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

PHP Security PHP Security Presentation Transcript

  • What Is Security? Security is a measurement, not a characteristic.
    • It is unfortunate that many software projects list security as a simple requirement to be met. In other words we can also say that how a website is secure from malicious user or any other security attacks.
    • It’s is also an growing problem that requires continually evolving solution. A good measure of secure application is it’s ability to predict and prevent future security problems, before someone devises an exploit.
    • As far as application design goes, security must be considered at all times; initial spec, implementation, testing and even maintenance. | | http://
  • Consequently PHP applications often end up working with sensitive data a. Unauthorized access to this data is unacceptable. b. To prevent problems a secure design is needed . | | http:// View slide
  • Basic Steps 1.Input fields must be sanitized before being used One of the key concepts you must accept is that user input is unreliable and not to be trusted. Partially lost in transmission between server & client. Corrupted by some in-between process. Modified by the malicoius user in an unexpected manner. Intentional attempt to gain unauthorized access or to crash the application. There are are many ways to sanitize data. One can use php inbuild function for the santization pupose or can use custom defined functions. Eg: All data passed to PHP (GET/POST/COOKIE) ends up being a string. Using strings where integers are needed is not only inefficient but also dangerous. if (!empty($_GET['id'])) { $id = (int) $_GET['id']; } else{ $id = 0; } As well as PHP comes with a ctype, extension that offers a very quick mechanism for validating string content. | | http:// View slide
  • if (!ctype_alnum($_GET['login'])) { echo "Only A-Za-z0-9 are allowed."; } if (!ctype_alpha($_GET['captcha'])) { echo "Only A-Za-z are allowed."; } You can use also your own customized validation.Like function validateEmail($email){ if($email == ""){ return false; } else{ if(!preg_match("(^[-w.]+@([-a-z0-9]+.)+[a-z]{2,4}$)i", $email)){ return false; } else{ return true; } } } | | http://
  • 2.Data Validations As we all know there are 2 types of validation for a web application. As follows: a. Client side validation b. Server side validation Client side validation is not reliable as an attacker can always bypass the client side validations or can shuts off the client-side script routines, for example, by disabling JavaScript. Hence Server side validation is a must for the security point of view, even if the client-side validation do exists. | | http://
  • 3. Accessing Input Data: There are a series of super-globals which offer very simple access to the input data. $_GET , $_POST, $_SERVER, $_REQUEST Using GET to send sensitive data causes security violation. When sensitive data is to be passed to the server, do not send it as a parameter in the query string like in: http://sitename/check_valid.php?cardnumber=1234567890123456. This is not appropriate because, the entire URL may be stored by the browser in its history, potentially exposing the sensitive information to someone else using the same machine later. The POST method uses the HTTP body to pass information and this is good in this case because the HTTP body is not logged. Using POST doesn’t offer enough protection. The data’s confidentiality and integrity are still at risk because the information is still sent in clear text. So the use of encryption technique is required, using SSL. Ddata is stored and accessed securely. | | http://
  • 4.Escaping Output Output is anything that leaves your application, bound for a client. The client, in this case, is anything from aWeb browser to a database server, and just as you should filter all incoming data, you should escape all outbound data. Whereas filtering input protects your application from bad or harmful data, escaping output protects the client and user from potentially damaging commands. To escape output intended for a Web browser, PHP provides htmlspecialchars()‏ and htmlentities(), EG: $_POST['data'] = “<script>alert('Security issues');</script>”; if (get_magic_quotes_gpc()) { $var = stripslashes($_POST['data']); } echo htmlentities($var ); | | http://
  • | | http://
  • 5.Register Globals The register_globals directive is disabled by default in PHP versions 4.2.0 and greater. Making register global on is a security risk. Therefore, one should always develop and deploy applications with register_globals disabled. Why it is a security risk? Let us consider the following block of codes <?php if (authenticated_user()) { $authorized = true; } if ($authorized) { include '/highly/sensitive/data.php'; } ?> | | http://
  • Since $authorized is left un-initialized if user authentication fails, an attacker could access privileged data by simply passing the value via GET. Solutions: Disable register_globals in PHP.ini. Already done by default as of PHP 4.2.0 . Code with error_reporting set to E_ALL. Allows you to see warnings about the use of un-initialized variables. Type sensitive validation conditions. Because input is always a string, type sensitive compare to a Boolean or an integer will always fail. A best practice is to initialize all variables. Error_reporting set to E_ALL, so that the use of an uninitialized variable won't be overlooked during development. | | http://
  • 6.Error Reporting: During development, making error reporting turned on is good practise. ini_set('error_reporting',E_ALL); However, when you put your site into production, this level of detail can be dangerous. You can't foresee all errors during development ,your program could run out of memory or disk space, for example. So, for safety's sake, on production sites you should disable the displaying of errors and instead log them to a file safely outside of your directory root; this way, the public can't see if anything goes wrong. error_reporting(E_ALL^E_NOTICE); // This is a 'sensible' reporting level ini_set('display_errors', 0); // Hide all error messages from the public ini_set('log_errors', 1); ini_set('error_log', 'path/to_your/log.txt'); /* Preferably a location outside of your web root */ | | http://
  • 7.SQL Injection SQL injection refers to the act of someone inserting a MySQL statement to be run on your database without your knowledge. Injection usually occurs when you ask a user for input, like their name, and instead of a name they give you a MySQL statement that you will unknowingly run on your database. One of the most common vulnerabilities is when logging in to a site. Take this example: $username = $_POST['username']; $password = $_POST['password']; $result = mysql_query(&quot; SELECT * FROM site_users WHERE username = '$username' AND password = '$password' &quot;); if ( mysql_num_rows($result) > 0 )‏ // logged in | | http://
  • If the attacker enters a valid username in the username field &quot;rob&quot; and the following in the password field ' OR 1=1 ' The resulting query will look like this: SELECT * FROM site_users WHERE username = 'rob' AND password = '' OR 1=1 Since the last crieteria will always be true.The user will be able to log in as rob without knowing rob's password. Prevnting Sql injection: The best way of cleaning input is using PHP's built in mysql_real_escape_string() function, this will escape characters such as ',&quot;&quot; and others. checking the magic quotes is on or off to avoid double escaping. | | http://
  • Function check_sql_injection($var){ if(get_magic_quotes_gpc()) { $var = stripslashes($var); } $var = mysql_real_escape_string($var); return $var; } Now this customized function can be used in sql query to prevent sql injection.. SELECT * FROM site_users WHERE username =check_sql_injection( '$username')‏ AND password = check_sql_injection( '$password)‏ | | http://
  • 8.XSS XSS stands for &quot;Cross Site Scripting&quot;, and refers to the act of inserting content, such as Javascript, into a page. Usually these attacks are used to steal cookies which often contain sensitive data such as login information. EG: $id = $_GET['id']; echo 'Displaying news item number '.$id; An attacker could pass string like this <script>window.location.href = &quot;' + document.cookie;</script> If a user passed this simple Javascript into the $_GET['id'] variable and convinced a user to click it, then the script would be executed and pass the user's cookie data onto the attacker, allowing them to log in as the user. It's really that simple. | | http://
  • Prevent XSS attacks? This attack works only if the application fails to escape output. Thus, it is easy to prevent this kind of attack with proper output escaping. The easiest way to do this is with PHP's built in strip_tags() function, which will remove HTML from a string rendering it harmless. If you just want to make the HTML safe without removing it altogether, then you need to run the input through htmlentities(), which will convert < and > to &lt; and &gt; respectively. | | http://
  • 9. Passwords need to be stored securely. Secure information, such as passwords and credit card numbers, should be stored in an encrypted format. This can be achivied using md5 command or any stronger method of algorithm. By using this, the attacker wont able access the password of a user. 10. Lock out functionality must be there for the login functionality. An attacker may continue to brute force the login functions until successful. So to prevent the same after a given number of unsuccessful logins over a period of time, the IP/User should be blocked or locked out for another a given period of time. For example 5 unsuccessful logins in 5 minutes may call for a lockout of 30 minutes for that IP/User. | | http://
  • 11.The email forms are vulnerable to email header injection Input should be validated and checked so that email header injection cannot occur. Escaping the CR and LF characters is needed and using captcha during mail form submission. | | http://
  • 12. Using Cookies Securely Cookies are an easy and useful way to keep user-specific information available. However, because cookies are sent to the browser's computer, they are vulnerable to spoofing or other malicious use. Follow these guidelines: Do not store any critical information in cookies. For example, do not store a user's password in a cookie, even temporarily. As a rule, do not store any sensitive information in a cookie. Set expiration dates on cookies to the shortest practical time you can. Avoid permanent cookies if possible. Consider encrypting information in cookies. Consider setting the Secure and HttpOnly properties on your cookies to true. | | http://
  • Mindfire Solutions Expertise in PHP
    • We have solid 8+ years of experience in PHP development.
    • Our PHP development team has gained expertise in more than 100 projects.
    • We have worked on and delivered various applications, systems and software with PHP across various industries. | | http://
  • For further queries contact us or call 1-248-686-1424 | | http://