Web Security

Web Vulnerability might take different forms, but the main way to attack a web service is through URI. The address of any document (i.e. file on the Internet) is its Uniform Resource Identifier (URI).

Every URI can also contain parameters. These are instructions you can send to the script located at that URI and that are appended to the URI starting with a ? and separated by ampersands. Normally, these parameters are not entered by end users but rather come from the HTML interface. You can send parameters to a script with the URI via form fields, links or any other thing in HTML that contains a URI: images, link elements, frames, anything that can take an href or src attribute. If an attacker can override any of these or add a new image to your HTML without you knowing it, they could point to their own URIs and send their own parameters.

Classification of Web Vulnerabilities

  • SQL Injection
  • Cross-Site Scripting (XSS)
  • Path Traversal
  • Cross-Site Request Forgery
  • Remote File Inclusion (RFI)
  • Phishing
  • Clickjacking

      • Web security company Cenzic released a report detailing trends and numbers related to Web security for the first and second quarters of 2009. A PDF of the report is available

      SQL Injection

      With an SQL injection, an attacker accesses your database by sending an SQL command to your server via the URI or form fields. This is easily worked around by sanitizing, but neglecting to do so can be fatal for your website.

      Cross-Site Scripting (XSS)

      Cross-site scripting is probably the biggest and most common problem. With it, an attacker injects JavaScript code into your document by adding it to the end of the URI as a parameter or in a form field. Once you have successfully injected JavaScript, you will be able to read out cookies; open forms that ask the user to enter their passwords or credit card details; execute viruses, worms and “drive-by downloads”; the lot. The reason is that JavaScript is not bound by any security model; any script on the page has the same rights, no matter which server it has come from. This is a big security problem with JavaScript and is something clever people are working on.

      The remedy for XSS is to be very paranoid about anything that comes via forms or the URI. You also need to be sure that your PHP is set up properly.

      Path Traversal

      Allowing for path or directory traversal on your server is an amazingly bad idea. You would be allowing people to list the folders on your server and to navigate from folder to folder. This allows attackers to go to folders with sensitive information or website functionality and have some fun.

      Cross-Site Request Forgery

      Cross-site request forgery (CSRF) exploits browsers and websites that allow for functionality to be called without really knowing that an actual user initiated it. The attack works by including a link or script in a page that accesses a site to which the user is known (or is supposed) to have been authenticated.

      Remote File Inclusion (RFI)

      With Remote file inclusion or code injection, an attacker uses a flaw in your website to inject code from another server to run on yours. It is in the same family as XSS but much more problematic because you have full access to your server (with JavaScript, you can steal cookies and call other code, but you can’t access the file system without resorting to tricks with Flash or Java Applets).

      The workaround is to turn off globals and to never ever assemble a URI from parameter or form data.

      Phishing

      Phishing is the technique of fooling people into entering information into a bad website. You show end users an interface that looks legit (for a bank or what have you) but that in reality sends their information to your database. The trick with phishing is to make the form really look like it comes from a website you trust.

      Clickjacking

      Clickjacking is a terribly clever way to use CSS and inline frames to trick users into clicking something without knowing it. Every action on a website that can be performed with a simple click can be exploited with this trick.

      Web Security Solutions

      Server Tweaks

      • Turn Off Folder Listing - allowing people to navigate your folders, you provide a lot of information about your file website's structure
      • Harden Your PHP - Turn Off Globals - with globals on, any variable you use and write out could become an attack
      • Turn Off Error Messages - they are a great source of information for attackers
      • Use PHPSecInfo to acquire detailed security information about your PHP setup.

      Safe Code Practices

      • HTML is pretty safe. It is simply converted into text—no interaction with the server or calculations—so not much can go wrong. HTML is fully visible - hiding things with CSS doesn’t make them go away. Never store sensitive information in HTML comments.
      • CSS is not really capable of doing much to the document and cannot access the server… for now. One problem with CSS is background images that point to URIs. You can inject code by somehow overriding these. The same applies to the @import property for other style sheets.
        Font-embedding in particular could become a big security issue, because fonts are binary data that could contain anything: harmless characters as well as viruses masquerading as a nice charset.
      • JavaScript is very powerful, though, which also means that it is a security issue. You should not try to do any of the following in JavaScript:
        • Store sensitive information (e.g. credit card numbers, any real user data).
        • Store cookies containing session data.
        • Try to protect content (e.g. right-click scripts, email obfuscation).
        • Replace your server or save on server traffic without a fallback.
        • Rely on JavaScript as the only means of validation. Attackers can turn off JavaScript and get full access to your system.
        • Trust any JavaScript that does not come from your server or a similar trusted source.
        • Trust anything that comes from the URI, HTML or form fields. All of these can be manipulated by attackers after the page has loaded. If you use document.write() on unfiltered data, you expose yourself to XSS attacks.
      • PHP (or Any Server-Side Language)
        • Never allow an unfiltered URI parameter to become part of a URI that you load in PHP or print out as an href or src in the HTML.
        • Generally, defining all of the variables you will use before you use them is a good idea
        • Writing your own validator function is another option

      Housekeeping

      One very important part of security is keeping your server clean. If you have old, insecure code lying around, it won’t matter whether your main website is hardened and up to date with the best security measures. Your server is as vulnerable as its weakest and least-maintained code.

      Check what you have on your server from time to time, and delete or move things that you are not interested in any more or couldn’t be bothered to maintain. Instead of deleting code, you could move it to a repository such as Google Code or GitHub and redirect the old folder to it.

      Page content is based on Web Security: Are You Part Of The Problem? By Christian Heilmann

      Updated: May 10, 2011