OWASP Top Ten Most Critical Web Application Vulnerabilities

Issue: Information from web requests is not validated before being used by a web application. Attackers can use these flaws to attack back end components through a web application.

Resolution: We validate all input and make sure that it is either blank or within the max length.

Issue: Restrictions on what authenticated users are allowed to do are not properly enforced. Attackers can exploit these flaws to access other users' accounts, view sensitive files, or use unauthorized functions.

Resolution: See answer to A3 below

Issue: Account credentials and session tokens are not properly protected. Attackers that can compromise passwords, keys, session cookies, or other tokens can defeat authentication restrictions and assume other users' identities.

Resolution: Access to areas of the site that are secure will only be granted with Cookie/Session authentication.  By requiring the cookie, it is not very likely that a session can be hijacked, since session hijacking is usually URL based session IDs.  This will mean user's with cookies disabled will not be able to access the secure sections of the site, but it will provide a greater degree of protection. The authentication mechanism also checks first digits of IP address.

The negative to this is that some users, specifically AOL users who get bumped around to many Ips in the course of a session may get bumped, but it will also provide a little bit of protection against session hijacking as well.

The authentication and session management is also modularized, so if any part of it becomes a security risk, it will be extremely easy to update it for the entire site.

Issue: The web application can be used as a mechanism to transport an attack to an end user's browser. A successful attack can disclose the end user?s session token, attack the local machine, or spoof content to fool the user.

Resolution: To eliminate the strong possibility for XSS Cross Site Scripting, I can strip_tags() from all data entered onto the site.  So, the majority (if not all) of XSS will be impossible since it usually requires some sort of scripting, which requires tags.  If need be, we could implement a system like phpbb boards where [b] and [/b] are used instead of tags to allow some formatting.

Issue: Web application components in some languages that do not properly validate input can be crashed and, in some cases, used to take control of a process. These components can include CGI, libraries, drivers, and web application server components.

Resolution: Buffer Overflows...I have no idea how to overcome this aspect as this is something that has more to do with the PHP engine itself.  The only part that may or may not affect the application of the site is this: "When web applications use libraries, such as a graphics library to generate images, they open themselves to potential buffer overflow attacks."  That seemed to be the only point on buffer overflows that involved the application rather than the server.  However, as it also points out, it is extremely difficult for hackers to do buffer overflow hacking.

Issue: Web applications pass parameters when they access external systems or the local operating system. If an attacker can embed malicious commands in these parameters, the external system may execute those commands on behalf of the web application.

Resolution: SQL Injections: Avoiding SQL Injections is fairly simple with PHP.  All you need to do is to use the method "mysql_escape_string()" method on any variables that are not hard-coded.  Or, if you are receiving an integer as input, like the ID of a person's profile, for instance, so that you know which profile to show, you can simply cast the variable as an integer.  If you cast it as an integer...any part of it that is a string will be deleted and if there is no number it will simply become 0 and no profile will be shown.

Currently our server is setup so that it automatically adds slashes to all variables as if the variable had had the method addslashes() run on it.  So, if I were to run mysql_escape_string() on the phrase "my friend's car" since the PHP engine automatically adds slashes it becomes "my friend\\'s car" and so running mysql_escape_string() on top of that would cause it to come out "my friend\\\'s car, and if you updated it without deleting the extra slashes the next time it would become: "My friend\\\\\\\\\\\\\\\'s car".  So our default setup on the server is automatically doing the job that mysql_escape_string() is doing.  However, if you would prefer it (since the mysql_escape_string() method is MADE for this particular issue), I can strip the slashes off of every variable after it's submitted and then run the mysql_escape_string() method on it after I strip the slashes that are added by default.  This would cure the above problem and would be using the PHP "preferred method" for escaping a string for use with MySQL--though it does add additional overhead.  Anyway, it's up to you.

Issue: Error conditions that occur during normal operation are not handled properly. If an attacker can cause errors to occur that the web application does not handle, they can gain detailed system information, deny service, cause security mechanisms to fail, or crash the server.

Resolution: Writing an error handling script so that the error is not displayed to the user is fairly simple.  Logging the errors depends a little more on the system and your preference.

Issue: Web applications frequently use cryptographic functions to protect information and credentials. These functions and the code to integrate them have proven difficult to code properly, frequently resulting in weak protection.

Resolution: PHP has a crypt() method that uses a one way encryption for passwords.  Since my guess is that the only encryption necessary would be passwords, this is what you'd want to use for protecting the data.

If there is other data that needs to be encrypted, we'll need to discuss this further.

Issue: Attackers can consume web application resources to a point where other legitimate users can no longer access or use the application. Attackers can also lock users out of their accounts or even cause the entire application to fail.

Resolution: Denial of Service--we can make no guarantee to keep this from taking place.  It states quite clearly that "there are no perfect defenses to these attacks," but I can easily keep session data to a minimum, which I usually attempt to do anyway...and session data is never stored until the person is validly logged in...so that will take care of one aspect mentioned in the docs.

Issue: Having a strong server configuration standard is critical to a secure web application. These servers have many configuration options that affect security and are not secure out of the box.

Resolution: Insecure Configuration Management.  This is in the ballpark of those who operate the server and is beyond the scope of application development.