Web Conference 2005 Writing PHP for ITS/ASET Web services Security Controls and Practices

General Security Concerns for Web Applications

PHP programming and security go hand-in-hand. Usually not the same hand and too often not yours. But there are a few things you should consider to make your programming efforts more secure.

1. Security is the WHOLE PICTURE, not just a certificate on a server. Don't be lulled to complacency at the sign of a "secure server." Security includes protecting all of the vectors by which data and systems can be attacked and compromised.

   • Encryption protects data. SSL protects data in transit between computers over the Internet. Other forms protect data when they reside in databases or in files.

   • Firewalls protect computer systems. They attempt to keep the "bad guys" out, but fail to protect from internal attacks. They do this by limiting which applications (e.g., Web, Email, Net-News, DNS, etc) are exposed for external access, but usually do little to protect the exposed applications. Firewalls may be useful for both servers and personal computers.

   • Permissions, ACLs and access control protect data from other people and programs while on a system.

   • Programs that are accessible by others may be broken into if the code has bugs or programming flaws. After all other considerations are met, the hardest part of securing an application is simply maintaining good bug-free code.

2. The only totally safe computer is one unplugged from the network, turned off, stored in 10-foot-thick concrete and buried at the bottom of the ocean...ok, so there are tradeoffs with security and functionality.

3. Least Privilege

   • Only give write access to files that need it and then only to the people and programs that need it.

   • Avoid giving write permission to folders whose files you don't mind loosing.

4. The Web server has one identity: one that is controlled by the PHP code that is written by anyone who has write access to Web space. It can be triggered by and is possibly exploitable by anyone in the world anonymously.

   •  In the case of the PHP server, this is the identity of httpd-php on the server and php.scripts.psu.edu when accessing PASS (DCE/DFS). Be warned of others using the PHP server.

5. Check your data at the door. When using user supplied data, including CGI parameters, Cookies, the Referer URL and the like, check it before using it in places where it can cause problems. Experts at system intrusion can send large amounts of data or invalid values in the least expected places.

   • Be wary of SQL injection; it may be lethal.

   • Use the size and maxlength attributes of the <input> HTML tag, but don't trust they will always work. The person or program talking to your Web server / PHP program may not always be a browser.

   • Don't even print remote user supplied data back to the browser without first escaping html special characters (e.g. via the htmlspecialchars() PHP function). Otherwise, nefarious sites may send unsuspecting users to your site with form parameters that print arbitrary JavaScript/ECMAScript to the browser. This can be used to bleed sensitive information, circumvent your security authorizations, or execute arbitrary actions on your site on the unsuspecting user's behalf. This is known as Cross Site Scripting (XSS).

     For an XSS example, try setting your favorite color to:

     blue"><script>alert("Should your site be susceptible, you will see this as a JavaScript alert message.")</script><"

     on the sample code given on form.php under "Your turn". Now remove the htmlspecialchars() function and try again. Don't forget to convert it back so you don't leave it vulnerable.

     This site and all sample code was updated to prevent XSS attacks on June 28-29, 2009.

6. If you can't build a brick house, tie your shoelaces... Learn about good security and programming practices. Be vigilant and security-minded. You will outrun most others and won't be the bear's lunch.

   • Well designed and written code means less buggy code. Less buggy code means more secure code.

     Clearly indented program code, with good choices of variable and function names, a healthy balance of comments, brevity of code wherever possible and a healthy comprehension of the language and programming environment (Apache + PHP, etc) all lead to better code.

   • This lesson is just the introduction. Please read more if you are interested in writing robust, secure and scalable applications.

Practical security

Security lesson review

1. Learn about security concerns of the GET vs POST method.

2. Learn about Email abuse issues with mail forms.

3. Learn about SQL injection.

4. Learn about sensitivity of cookies and session management.

If you have any questions, feel free to ask me. Content by: Jeff D'Angelo <jcd@psu.edu> © 2005 See the source for this page Last update on: Mon Jun 29, 2009, 10:50:17 PM