Today I’m going to be writing about one the most, if not the most, common yet dangerous vulnerabilities that hackers can take advantage of, called cross-site scripting. Cross-site scripting is similar to SQL injections in that it takes advantage of the fact that a developer wasn’t one hundred percent careful when creating their web application. Basically, it is the injection of malicious code into a website through its user input fields. 

Here’s how it works. Let’s suppose you have a website with a commenting functionality. All a user has to do to leave a comment is to type it into the comment box and press “submit”. Your website was most likely created with HTML. HTML is a tag-based language, where text is written in between specialised tags that dictate how the text is interpreted by the site. For example, writing text between a <b> and a closing </b> tag would make the text in between appear bolded. There is also a specialised <script> tag that will execute any JavaScript command inside it, and that is invisible to users. If your website’s commenting functionality isn’t written to escape the tag so that the script can’t run, the website will essentially belong to the malicious hacker.

Since cross-site scripting attacks rely on the host website in order to harm its users, it can be said that there are two broad types of attacks: Persistent Scripts and Non-Persistent Scripts. Non-Persistent Scripts only run once and are usually done for test purposes to see whether or not a vulnerability exists. Persistent Scripts, however, are the ones that actually do the damage. If someone was to write a persistent script on your website’s comment section, it would be completely invisible, and it can do anything from stealing cookie information in order to gain access to a user’s account, to setting a worm in a user’s MySpace account, which would make any other MySpace user add the first as a friend, and then bring the worm over to their own account, resulting in a user gaining millions of friends overnight. The latter really happened, and the perpetrator got three years probation and a twenty thousand dollars fine. Just goes to show the importance of being careful as a security professional (or criminal).

  • Cross-Site Scripting (“XSS“)
    • Hackers can inject JavaScript into a web page
    • Used to steal cookies a session data
    • Often very successful just because browser trusts JavaScript
      • Protection:
        • Sanitize any dynamic context that gets output to browser (HTML, JavaScript, JSON, XML…)
        • Pay special attention to data that come directly from URLs or forms
        • Be careful about database data, cookies, session data
        • Use Whitelists to allow certain HTML tags and sanitize everything else
    • Cross-Site Request Forgery (CSRF)
      • Hackers tricks user into making a request to your server
      • Used for fraudulent clicks
      • Forging login request
        • Protection
          • Accept POST request only
          • Use a “form token” in user’s section
          • Add a hidden field to forms with form token as value
          • Compare session form token and submitted form token
          • Store the token generation time in user’s session
    • SQL Injection
      • Hacker is able to execute arbitrary SQL request in order to probe database schema, steal data(usernames, passwords, credit cards, encrypted data), assign elevated privileges, truncate or drop tables
        • Protection
          • Use limited privileges to application’s database user
          • Sanitize input
          • Escape for SQL using libraries
          • Use prepared statements
    • URL manipulation
      • Editing the URL string to probe the site
      • Can be used for revealing private information, performing restricted actions
        • Protection
      • Remember that URLs are exposed and easily editable
      • Implement proper access control
      • Keep error messages vague
      • Clarify your GET and POST requests, only POST requests should be used for making changes
    • Cookie Stealing
      • Cookie data is visible to users
      • Cookies can be stolen using XSS attack
      • Remember that cookies can be sniffed by observing network traffic by using packet analyzers (most popular Wireshark)
        • Protection
          • Put only non sensitive data in cookies
          • Use HttpOnly cookies
        • Use HTTPs cookies
        • Set cookie expiration date
        • Set cookie domain, sub domain and path
        • Encrypt cookie data
        • User server side sessions instead of client side cookies
    • Session hijacking
      • Stealing session ID is similar to stealing cookie but much more valuable
      • Can be used to steal personal info, passwords
      • Often done by network sniffing
      • Never use open wireless networks at coffee shops for transmitting sensitive data
      • Variation of session hijacking is session fixation
      • Session fixation is opposite to session hijacking, it trick a user into a hacker provided session identifier
        • Protection
          • Use SSL
          • Save user agent in session and confirm it (not ideal method)
          • Check IP address of a computer who is making a request (not ideal as well)
          • Use HttpOnly cookies
          • Regenerate session ID periodically, at key points, especially important to regenerate after log in
          • Expire and remove old session files regularly and keep track of last activity in session
        • Do not accept session identifier from from GET or POST variables, session identifier should come from only one place – cookies
    • Remote system execution attack

      • It’s the most dangerous attack when hacker remotely run operating system commands on a web server
        • Protection
          • Avoid system execution keywords (they are language specific)
          • Perform system execution with extra caution
          • Sanitize any dynamic data carefully
          • Understand system commands and their syntax
          • Add additional data validation
    • File upload abuse
      • Can be used to upload too much data (quantity, file size)
      • Can be used to upload warm or virus
        • Protection
          • Require user authentication, no anonymous uploads
          • Limit maximum upload size
          • Limit allowable file formats, file extensions
          • Use caution when opening uploaded file
          • Do not host uploaded files which have not been verified
    • Denial of Service (DoS) attack

      • Attempt to make a server unavailable to users
      • Usually performed by overloading a server with requests
      • Includes DNS and routing disruption
      • If performed by distributed network pf computers it called DDoS
        • Protection
          • Properly configure firewalls, IDS, switches, load balancers and routers
        • Collection of reverse proxies
        • Map you infrastructure
        • Keep infrastructure up to date
        • Make network traffic visible
        • Develop DRP plan
        • Consider changing IP address
        • “Black hole” or “null route” traffic