8 minute read


This post covers web security for Internet Programming.

Website Security

  • is act of protecting websites from unauthorized access, use, modification, destruction, or disruption
  • Effective website security requires design effort across the whole of the website: in your web application, the configuration of the web server, your policies for creating and renewing passwords, and the client-side code.
  • If you’re using a server-side web framework, it will almost certainly enable “by default” robust and well-thought-out defense mechanisms against a number of the more common attacks.
  • Other attacks can be mitigated through your web server configuration, for example by enabling HTTPS.
  • Finally, there are publicly available vulnerability scanner tools that can help you find out if you’ve made any obvious mistakes.

Website security threats

  • Cross-Site Scripting (XSS)

    • class of attacks that allow an attacker to inject client-side scripts through the website into the browsers of other users.

    • Because the injected code comes to the browser from the site, the code is trusted and can do things like send the user’s site authorization cookie to the attacker.

    • When the attacker has the cookie, they can log into a site as though they were the user and do anything the user can, such as access their credit card details, see contact details, or change passwords.

    • The XSS vulnerabilities are divided into reflected and persistent, based on how the site returns the injected scripts to a browser.

    • Reflected XSS vulnerability

      • occurs when user content that is passed to the server is returned immediately and unmodified for display in the browser. Any scripts in the original user content will be run when the new page is loaded.
      • For example, consider a site search function where the search terms are encoded as URL parameters, and these terms are displayed along with the results. An attacker can construct a search link that contains a malicious script as a parameter (e.g.,<script%20src=””></script>) and email it to another user. If the target user clicks this “interesting link”, the script will be executed when the search results are displayed.
      • This may give the attacker all the information they need to enter the site as the target user, potentially making purchases as the user or sharing their contact information.
    • Persistent XSS vulnerability

      • occurs when the malicious script is stored on the website and then later redisplayed unmodified for other users to execute unwittingly.
      • For example, a discussion board that accepts comments that contain unmodified HTML could store a malicious script from an attacker.
      • When the comments are displayed, the script is executed and can send to the attacker the information required to access the user’s account. This sort of attack is extremely popular and powerful, because the attacker might not even have any direct engagement with the victims.
    • While the data from POST or GET requests is the most common source of XSS vulnerabilities, any data from the browser is potentially vulnerable, such as cookie data rendered by the browser, or user files that are uploaded and displayed.

    • The best defense against XSS vulnerabilities is to remove or disable any markup that can potentially contain instructions to run the code. For HTML this includes elements, such as

    • The process of modifying user data so that it can’t be used to run scripts or otherwise affect the execution of server code is known as input sanitization. Many web frameworks automatically sanitize user input from HTML forms by default.
  • SQL injection

    • SQL injection vulnerabilities enable malicious users to execute arbitrary SQL code on a database, allowing data to be accessed, modified, or deleted irrespective of the user’s permissions.

    • A successful injection attack might spoof identities, create new identities with administration rights, access all data on the server, or destroy/modify the data to make it unusable.

    • SQL injection types include Error-based SQL injection, SQL injection based on boolean errors, and Time-based SQL injection.

    • This vulnerability is present if user input that is passed to an underlying SQL statement can change the meaning of the statement.

    • For example, the following code is intended to list all users with a particular name (userName) that has been supplied from an HTML form:

      • statement = "SELECT * FROM users WHERE name = '" + userName + "';"
      • SELECT * FROM users WHERE name = 'a';DROP TABLE users; SELECT * FROM userinfo WHERE 't' = 't';
      • # solution is to escape char
        SELECT * FROM users WHERE name = 'a\';DROP TABLE users; SELECT * FROM userinfo WHERE \'t\' = \'t';
  • Cross-Site Request Forgery (CSRF)

    • CSRF attacks allow a malicious user to execute actions using the credentials of another user without that user’s knowledge or consent.
      • John is a malicious user who knows that a particular site allows logged-in users to send money to a specified account using an HTTP POST request that includes the account name and an amount of money.
      • John constructs a form that includes his bank details and an amount of money as hidden fields, and emails it to other site users (with the Submit button disguised as a link to a “get rich quick” site).
      • If a user clicks the submit button, an HTTP POST request will be sent to the server containing the transaction details and any client-side cookies that the browser associated with the site (adding associated site cookies to requests is normal browser behavior).
      • The server will check the cookies, and use them to determine whether or not the user is logged in and has permission to make the transaction.
      • The result is that any user who clicks the Submit button while they are logged in to the trading site will make the transaction. John gets rich.
    • One way to prevent this type of attack is for the server to require that POST requests include a user-specific site-generated secret.
    • The secret would be supplied by the server when sending the web form used to make transfers.
    • This approach prevents John from creating his own form, because he would have to know the secret that the server is providing for the user.
    • Even if he found out the secret and created a form for a particular user, he would no longer be able to use that same form to attack every user.
    • Web frameworks often include such CSRF prevention mechanisms.
  • Other threats

    • Clickjacking
      • In this attack, a malicious user hijacks clicks meant for a visible top-level site and routes them to a hidden page beneath. This technique might be used, for example, to display a legitimate bank site but capture the login credentials into an invisible <iframe> controlled by the attacker.
      • Clickjacking could also be used to get the user to click a button on a visible site, but in doing so actually unwittingly click a completely different button. As a defense, your site can prevent itself from being embedded in an iframe in another site by setting the appropriate HTTP headers.
    • Denial of Service (DoS).
      • DoS is usually achieved by flooding a target site with fake requests so that access to a site is disrupted for legitimate users.
      • The requests may be numerous, or they may individually consume large amounts of resource (e.g., slow reads or uploading of large files).
      • DoS defenses usually work by identifying and blocking “bad” traffic while allowing legitimate messages through.
      • These defenses are typically located before or in the web server (they are not part of the web application itself).
    • Directory Traversal (File and disclosure).
      • In this attack, a malicious user attempts to access parts of the web server file system that they should not be able to access.
      • This vulnerability occurs when the user is able to pass filenames that include file system navigation characters (for example, ../../). The solution is to sanitize input before using it.
    • File Inclusion.
      • In this attack, a user is able to specify an “unintended” file for display or execution in data passed to the server.
      • When loaded, this file might be executed on the web server or the client-side (leading to an XSS attack). The solution is to sanitize input before using it.
    • Command Injection.
      • Command injection attacks allow a malicious user to execute arbitrary system commands on the host operating system.
      • The solution is to sanitize user input before it might be used in system calls.