Cross-frame scripting vulnerabilities occur when an application:

1. Allows itself to be included inside an iframe.
2. Fails to specify framing policy via the X-Frame-Options header.
3. Uses poor protection, such as JavaScript-based frame busting logic.

Cross-frame scripting vulnerabilities often form the basis of clickjacking exploits that attackers may use to conduct cross-site request Forgery or phishing attacks.

Cross-Frame Scripting vulnerabilities occur when an application:
1. Allows itself to be framed inside an Iframe
2. Fails to specify framing policy via X-Frame-Options header
3. Uses of poor protection such as JavaScript based frame busting logic
Cross-Frame Scripting vulnerabilities often form the basis of Clickjacking exploits that attackers can use to conduct Cross-Site Request Forgery or phishing attacks.

A cross-site request forgery (CSRF) vulnerability occurs when:
1. A Web application uses session cookies.

2. The application acts on an HTTP request without verifying that the request was made with the user's consent.

By default, Visualforce pages are rendered with hidden form fields that serve as anti-CSRF tokens. These tokens are included in the requests that are sent from within the page, and the server checks the validity of the tokens before executing the corresponding action methods or commands. However, this built-in defense does not apply to page action methods and custom page controller constructors because they are executed before the anti-CSRF tokens are generated during page load.

Example 1: The following Visualforce page declares a custom contoller MyAccountActions and a page action method pageAction(). The pageAction() method is executed when visiting the page URL, and the server does not check for anti-CSRF tokens.

<apex:page controller="MyAccountActions" action="{!pageAction}">
    ...
</apex:page>

public class MyAccountActions {

    ...
    public void pageAction() {
        Map<String,String> reqParams = ApexPages.currentPage().getParameters();
        if (params.containsKey('id')) {
            Id id = reqParams.get('id');
            Account acct = [SELECT Id,Name FROM Account WHERE Id = :id];
            delete acct;
        }
    }
    ...
}

An attacker might set up a malicious website that contains the following code:

<img src="http://my-org.my.salesforce.com/apex/mypage?id=YellowSubmarine" height=1 width=1/>

If an administrator for the Visualforce page visits the malicious page while having an active session on the site, they will unwittingly delete accounts for the attacker.

A cross-site request forgery (CSRF) vulnerability occurs when:
1. A web application uses session cookies.

2. The application acts on an HTTP request without verifying that the request was made with the user's consent.



A nonce is a cryptographic random value that is sent with a message to prevent replay attacks. If the request does not contain a nonce that proves its provenance, the code that handles the request is vulnerable to a CSRF attack (unless it does not change the state of the application). This means a web application that uses session cookies has to take special precautions to ensure that an attacker can't trick users into submitting bogus requests. Imagine a web application that allows administrators to create new accounts as follows:

  var req = new XMLHttpRequest();
  req.open("POST", "/new_user", true);
  body = addToPost(body, new_username);
  body = addToPost(body, new_passwd);
  req.send(body);

An attacker might set up a malicious web site that contains the following code.

  var req = new XMLHttpRequest();
  req.open("POST", "http://www.example.com/new_user", true);
  body = addToPost(body, "attacker");
  body = addToPost(body, "haha");
  req.send(body);

If an administrator for example.com visits the malicious page while she has an active session on the site, she will unwittingly create an account for the attacker. This is a CSRF attack. It is possible because the application does not have a way to determine the provenance of the request. Any request could be a legitimate action chosen by the user or a faked action set up by an attacker. The attacker does not get to see the Web page that the bogus request generates, so the attack technique is only useful for requests that alter the state of the application.

Applications that pass the session identifier in the URL rather than as a cookie do not have CSRF problems because there is no way for the attacker to access the session identifier and include it as part of the bogus request.

A cross-site request forgery (CSRF) vulnerability occurs when:
1. A Web application uses session cookies.

2. The application acts on an HTTP request without verifying that the request was made with the user's consent.

A nonce is a cryptographic random value that is sent with a message to prevent replay attacks. If the request does not contain a nonce that proves its provenance, the code that handles the request is vulnerable to a CSRF attack (unless it does not change the state of the application). This means a Web application that uses session cookies has to take special precautions in order to ensure that an attacker can't trick users into submitting bogus requests. Imagine a Web application that allows administrators to create new accounts by submitting this form:

<form method="POST" action="/new_user" >
Name of new user: <input type="text" name="username">
Password for new user: <input type="password" name="user_passwd">
<input type="submit" name="action" value="Create User">
</form>

An attacker might set up a Web site with the following:

<form method="POST" action="http://www.example.com/new_user">
<input type="hidden" name="username" value="hacker">
<input type="hidden" name="user_passwd" value="hacked">
</form>
<script>
document.usr_form.submit();
</script>

If an administrator for example.com visits the malicious page while she has an active session on the site, she will unwittingly create an account for the attacker. This is a CSRF attack. It is possible because the application does not have a way to determine the provenance of the request. Any request could be a legitimate action chosen by the user or a faked action set up by an attacker. The attacker does not get to see the Web page that the bogus request generates, so the attack technique is only useful for requests that alter the state of the application.

Applications that pass the session identifier in the URL rather than as a cookie do not have CSRF problems because there is no way for the attacker to access the session identifier and include it as part of the bogus request.

A cross-site request forgery (CSRF) vulnerability occurs when:
1. A Web application uses session cookies.

2. The application acts on an HTTP request without verifying that the request was made with the user's consent.

A nonce is a cryptographic random value that is sent with a message to prevent replay attacks. If the request does not contain a nonce that proves its provenance, the code that handles the request is vulnerable to a CSRF attack (unless it does not change the state of the application). This means a Web application that uses session cookies has to take special precautions in order to ensure that an attacker can't trick users into submitting bogus requests. Imagine a Web application that allows administrators to create new accounts as follows:

By default Play Framework adds protection against CSRF, but it can be disabled globally or for certain routes.

Example 1: The following route definition disables the CSRF protection for the buyItem controller method.

+ nocsrf
POST    /buyItem     controllers.ShopController.buyItem

If a user is tricked into visiting a malicious page while she has an active session for shop.com, she will unwittingly buy items for the attacker. This is a CSRF attack. It is possible because the application does not have a way to determine the provenance of the request. Any request could be a legitimate action chosen by the user or a faked action set up by an attacker. The attacker does not get to see the Web page that the bogus request generates, so the attack technique is only useful for requests that alter the state of the application.

Applications that pass the session identifier in the URL rather than as a cookie do not have CSRF problems because there is no way for the attacker to access the session identifier and include it as part of the bogus request.

A cross-site request forgery (CSRF) vulnerability occurs when:
1. A Web application uses session cookies.

2. The application acts on an HTTP request without verifying that the request was made with the user's consent.



A nonce is a cryptographic random value that is sent with a message to prevent replay attacks. If the request does not contain a nonce that proves its provenance, the code that handles the request is vulnerable to a CSRF attack (unless it does not change the state of the application). This means a Web application that uses session cookies has to take special precautions in order to ensure that an attacker can't trick users into submitting bogus requests. Imagine a Web application that allows administrators to create new accounts by submitting this form:

<form method="POST" action="/new_user" >
  Name of new user: <input type="text" name="username">
  Password for new user: <input type="password" name="user_passwd">
    <input type="submit" name="action" value="Create User">
</form>

An attacker might set up a Web site with the following:

<form method="POST" action="http://www.example.com/new_user">
  <input type="hidden" name="username" value="hacker">
  <input type="hidden" name="user_passwd" value="hacked">
</form>
<script>
  document.usr_form.submit();
</script>

If an administrator for example.com visits the malicious page while she has an active session on the site, she will unwittingly create an account for the attacker. This is a CSRF attack. It is possible because the application does not have a way to determine the provenance of the request. Any request could be a legitimate action chosen by the user or a faked action set up by an attacker. The attacker does not get to see the Web page that the bogus request generates, so the attack technique is only useful for requests that alter the state of the application.

Applications that pass the session identifier in the URL rather than as a cookie do not have CSRF problems because there is no way for the attacker to access the session identifier and include it as part of the bogus request.

Cross-Site WebSocket Hijacking occurs when a user is tricked into visiting a malicious site that will establish a WebSocket connection with a legitimate backend server. The initial HTTP request used to ask the server for upgrading to WebSocket protocol is a regular HTTP request and so, the browser will send any cookies bound to the target domain including any session cookies. If the server fails to verify the Origin header, it will allow any malicious site to impersonate the user and establish a bidirectional WebSocket connection without the user even noticing.

File-based cross-zone scripting occurs when the following conditions are met:

1. A file is loaded that could allow scripts to be run within your application.


2. The script loaded is viewed as having the same origin as the running application (file://).

When both of these conditions are met a series of attacks may be enabled, especially if other parties determine trust based on whether the information is coming from within the boundaries of your application.

Example 1: The following code uses the UIWebView.loadRequest(_:) method to load a local file:

...
NSURL *url = [[NSBundle mainBundle] URLForResource: filename withExtension:extension]; 
[webView loadRequest:[[NSURLRequest alloc] initWithURL:url]];
...

In Example 1, the WebView engine treats everything loaded with UIWebView.loadRequest(_:) with a URL starting with file:// as being in the privileged local file origin.

There are a few typical ways for an attacker to leverage a file-based cross-zone scripting vulnerability when loading from a file:

- The local file may be controlled by the attacker. For example, the attacker may send the file to its victim which then proceeds to store it on the vulnerable application (for example: a cloud storage application)
- The local file could be manipulated by an attacker, who could inject script into the file. This will be dependent on file permissions, where the file is located, or race conditions where a file may be saved and then loaded (there could be a time window for modification).
- The file may call out to an external resource. This may occur when the loaded file retrieves scripts from an external resource.
- The loaded file may contain cross-site scripting vulnerabilities. If the file being loaded contains injected code, this code may then be run in the context of your application. The injected code does not need to be JavaScript code - injected HTML may also enable defacements or denial of service attacks.

If the attacker-controlled file is loaded locally with a file:// URL, the Same Origin Policy will allow the scripts in this file to access any other file from the same origin, which may let an attacker access any local files containing sensitive information.

File-based cross-zone scripting occurs when the following conditions are met:

1. A file is loaded that could allow scripts to be run within your application.


2. The script loaded is viewed as having the same origin as the running application (file://).

When both of these conditions are met a series of attacks may be enabled, especially if other parties determine trust based on whether the information is coming from within the boundaries of your application.

Example 1: The following code uses the UIWebView.loadRequest(_:) method to load a local file:

...
let url = Bundle.main.url(forResource: filename, withExtension: extension)
self.webView!.load(URLRequest(url:url!))
...

In Example 1, the WebView engine treats everything loaded with UIWebView.loadRequest(_:) with a URL starting with file:// as being in the privileged local file origin.

There are a few typical ways for an attacker to leverage a file-based cross-zone scripting vulnerability when loading from a file:

- The local file may be controlled by the attacker. For example, the attacker may send the file to its victim which then proceeds to store it on the vulnerable application (for example: a cloud storage application)
- The local file could be manipulated by an attacker, who could inject script into the file. This will be dependent on file permissions, where the file is located, or race conditions where a file may be saved and then loaded (there could be a time window for modification).
- The file may call out to an external resource. This may occur when the loaded file retrieves scripts from an external resource.
- The loaded file may contain cross-site scripting vulnerabilities. If the file being loaded contains injected code, this code may then be run in the context of your application. The injected code does not need to be JavaScript code - injected HTML may also enable defacements or denial of service attacks.

If the attacker-controlled file is loaded locally with a file:// URL, the Same Origin Policy will allow the scripts in this file to access any other file from the same origin, which may let an attacker access any local files containing sensitive information.

GraphiQL is an in-browser tool that leverages the GraphQL schema introspection mechanism to provide a graphical interface for GraphQL API development and testing. GraphiQL helps users explore GraphQL schemas as well as compose and execute GraphQL queries.

Allowing access to GraphiQL in production is not recommended because enabling introspection of your GraphQL schemas through GraphiQL can pose a risk to your overall security posture. An attacker can use GraphiQL and introspection to obtain implementation details from a GraphQL schema that enables them to perform a more targeted attack. GraphQL schemas might leak information such as internally used fields, descriptions, and deprecation notes that are not intended for public consumption.

Example 1: The following code initializes a GraphQL endpoint with GraphiQL enabled:

app.add_url_rule('/graphql', view_func=GraphQLView.as_view(
  'graphql',
  schema = schema,
  graphiql = True
))

The GraphQL introspection capability enables anyone to query a GraphQL server for information about the current schema. An interested party can issue GraphQL introspection queries to retrieve a complete view of a schema's available operations, data types, fields, and documentation.

GraphQL introspection offers a significant utility in the context of developing and sharing information about GraphQL APIs. Introspection is a powerful GraphQL feature that can facilitate integration with various tools. For example, an IDE can leverage schema introspection to provide enhanced features for developing and testing GraphQL APIs.

However, allowing anyone to query your GraphQL schemas in production can pose a risk to your overall security posture. An attacker can use introspection to obtain implementation details from a GraphQL schema that enables them to perform a more targeted attack. GraphQL schemas can leak information such as internally used fields, descriptions, and deprecation notes that might not be intended for public consumption.

Example 1: The following code initializes a GraphQL.js endpoint with schema introspection enabled by default:

app.use('/graphql', graphqlHTTP({
    schema
}));

The GraphQL introspection capability enables anyone to query a GraphQL server for information about the current schema. Any interested party can issue GraphQL introspection queries to retrieve a complete view of a schema's available operations, data types, fields, and documentation.

GraphQL introspection offers significant utility in the context of developing and sharing information about GraphQL APIs. Introspection is a powerful GraphQL feature that can facilitate integration with various tools. For example, an IDE can leverage schema introspection to provide enhanced features for developing and testing GraphQL APIs.

However, allowing anyone to query your GraphQL schemas in production can pose a risk to your overall security posture. An attacker can use introspection to obtain implementation details from a GraphQL schema that enables them to perform a more targeted attack. GraphQL schemas might leak information such as internally used fields, descriptions, and deprecation notes that are not intended for public consumption.

Example 1: The following code initializes a GraphQL endpoint with schema introspection enabled by default:

app.add_url_rule('/graphql', view_func=GraphQLView.as_view(
  'graphql',
  schema = schema
))

Programmers often trust the contents of hidden fields, expecting that users will not be able to view them or manipulate their contents. Attackers will violate these assumptions. They will examine the values written to hidden fields and alter them or replace the contents with attack data.

Example 1:

  HtmlInputHidden hidden = new HtmlInputHidden();

If hidden fields carry sensitive information, this information will be cached the same way the rest of the page is cached. This can lead to sensitive information being tucked away in the browser cache without the user's knowledge.

Programmers often trust the contents of hidden fields, expecting that users will not be able to view them or manipulate their contents. Attackers will violate these assumptions. They will examine the values written to hidden fields and alter them or replace the contents with attack data.

Example 1: An <input> tag of type hidden indicates the use of a hidden field.

<input type="hidden">

If hidden fields carry sensitive information, this information will be cached the same way the rest of the page is cached. This can lead to sensitive information being tucked away in the browser cache without the user's knowledge.