Web Application Security Guidance - Revision history

Sherif: minor test

2017-11-25T11:15:29Z

minor test

Sherif: lll

2017-11-25T11:04:45Z

lll

Sherif: minor edit

2017-11-25T11:03:07Z

minor edit

Sherif at 22:36, 13 November 2017

2017-11-13T22:36:05Z

Sherif: draft

2017-11-13T22:28:07Z

draft

Sherif: d

2017-11-13T22:17:18Z

Show changes

Sherif at 22:12, 13 November 2017

2017-11-13T22:12:47Z

Show changes

Sherif: Draft

2017-11-13T21:57:10Z

Draft

Show changes

Sherif: Draft

2017-11-13T21:42:11Z

Draft

New page

Service Side Attacks
These are attacks that target the web application/service directly.
{| class="wikitable"
|-
! Header text !! Header text !! Header text !! Header text !! Header text !! Header text
|-
| Example || Example || Example || Example || Example || Example
|-
| Example || Example || Example || Example || Example || Example
|-
| Example || Example || Example || Example || Example || Example
|-
| Example || Example || Example || Example || Example || Example
|-
| Example || Example || Example || Example || Example || Example
|-
| Example || Example || Example || Example || Example || Example
|-
| Example || Example || Example || Example || Example || Example
|-
| Example || Example || Example || Example || Example || Example
|-
| Example || Example || Example || Example || Example || Example
|-
| Example || Example || Example || Example || Example || Example
|}

Client Side Attacks
These are attacks that target the user's browser as they require use action to be successful.
{| class="wikitable"
|-
! Header text !! Header text !! Header text !! Header text !! Header text !! Header text !! Header text !! Header text !! Header text
|-
| Example || Example || Example || Example || Example || Example || Example || Example || Example
|-
| Example || Example || Example || Example || Example || Example || Example || Example || Example
|-
| Example || Example || Example || Example || Example || Example || Example || Example || Example
|-
| Example || Example || Example || Example || Example || Example || Example || Example || Example
|-
| Example || Example || Example || Example || Example || Example || Example || Example || Example
|-
| Example || Example || Example || Example || Example || Example || Example || Example || Example
|}

← Older revision		Revision as of 11:15, 25 November 2017
Line 447:		Line 447:

	Builders should write secure APIs and follow secure development guidelines that are not vulnerable to RFD.		Builders should write secure APIs and follow secure development guidelines that are not vulnerable to RFD.
−	\|}
−
−	~~== Testing Table formatting ==~~
−	~~{\| class="wikitable"~~
−	~~!Description~~
−	~~!das`fwsdfsfsd~~
−	~~!asfasfasfasfasfas~~
−	~~!asfsafsaf~~
−	\|-
−	\|
−	\|
−	\|
−	\|
−	\|-
−	\|
−	\|
−	\|
−	\|
−	\|-
−	\|
−	\|
−	\|
−	\|
	\|}		\|}

← Older revision		Revision as of 11:04, 25 November 2017
Line 450:		Line 450:

	== Testing Table formatting ==		== Testing Table formatting ==
		+	{\| class="wikitable"
		+	!Description
		+	!das`fwsdfsfsd
		+	!asfasfasfasfasfas
		+	!asfsafsaf
		+	\|-
		+	\|
		+	\|
		+	\|
		+	\|
		+	\|-
		+	\|
		+	\|
		+	\|
		+	\|
		+	\|-
		+	\|
		+	\|
		+	\|
		+	\|
		+	\|}

@@ Line 333: / Line 333: @@
 # Existence of HTML     tags whose presence cause immediate access to an http[s] resource; for     example the image tag img
+|
 Manually testing sensitive live web pages is the preferred method, however tools such as BURP suite do have CSRF automated scanning rules available.
@@ Line 346: / Line 345: @@
 * observe the result, i.e. check if the web server executed the request.
+|
 If session management of a sensitive form relies only values such as a cookie then the application is vulnerable.
 |To mitigate against a CSRF attack, the web application needs proof that the user initiated the actions being sent to the site.
@@ Line 414: / Line 412: @@
 <code>response.sendRedirect(request.getParameter("url"));</code>
+|
 Safe use of redirects and forwards can be done in a number of ways:
 * Do not allow the url as user input for the destination. This can usually be done. In this case, you should have a method to validate URL.
@@ Line 451: / Line 448: @@
 Builders should write secure APIs and follow secure development guidelines that are not vulnerable to RFD.
 |}

@@ Line 292: / Line 292: @@
 <nowiki>http://techblog.netflix.com/2015/08/announcing-sleepy-puppy-cross-site.html</nowiki>
+|
 If a feature echos user supplied data without encoding, then the data can be interpreted as code in HTML.
 |To help defend against Persistent Cross Site Scripting its important to ensure that user-supplied data is output encoded before being served by the application to other users.
@@ Line 334: / Line 333: @@
 # Existence of HTML     tags whose presence cause immediate access to an http[s] resource; for     example the image tag img
+|
+|
-−
 |-
+|
@@ Line 349: / Line 372: @@
 There have also been clickjacking attacks abusing Facebook's "Like" functionality. Attackers can trick logged-in Facebook users to arbitrarily like fan pages, links, groups, etc
+|Testing for clickjacking can be done by creating an HTML page and include an iframe of a sensitive page of the web application. If the iFrame renders then the vulnerability exists.
+|During code review, check if pages with sensitive functionality have either a Content Security Policy header with with restricted frame-ancestors directive OR a restricted X-Frame-Options response header
+|There are two many ways to defend against Clickjacking at the browser level:
 |-
+|
 === '''Insecure URL Redirects''' ===
 |Insecure URL Redirection is an input validation flaw that exists when an application accepts an user controlled input which specifies a link that leads to an external URL that could be malicious. This kind of vulnerability could be used to accomplish a phishing attack or redirect a victim to an infection page.
+|
-−
+Safe use of redirects and forwards can be done in a number of ways:
 |-
+|
@@ Line 368: / Line 429: @@
 Example: <nowiki>http://pivotal.io/security/cve-2015-5211</nowiki>
+|For a Reflected File Download attack to be successful, there are three simple requirements:
-−
+) Reflected – Some user input is being "reflected" to the response content. This is used to inject shell commands.
 |}

@@ Line 8: / Line 8: @@
+|
 === '''Command Injection''' ===
-| OS command injection is a technique used via a web interface in order to execute OS commands on a web server. The user supplies operating system commands through a web interface in order to execute OS commands. Any web interface that is not properly sanitized is subject to this exploit. With the ability to execute OS commands, the user can upload malicious programs or even obtain passwords. OS command injection is preventable when security is emphasized during the design and development of applications. || Appending a semicolon to the end of a URL query parameter followed by an operating system command, will execute the command. %3B is url encoded and decodes to semicolon. This is because the ; is interpreted as a command seperator.
+| OS command injection is a technique used via a web interface in order to execute OS commands on a web server. The user supplies operating system commands through a web interface in order to execute OS commands. Any web interface that is not properly sanitized is subject to this exploit. With the ability to execute OS commands, the user can upload malicious programs or even obtain passwords. OS command injection is preventable when security is emphasized during the design and development of applications. || Appending a semicolon to the end of a URL query parameter followed by an operating system command, will execute the command. %3B is url encoded and decodes to semicolon. This is because the ; is interpreted as a command separator.
-Example: <nowiki>http://sensitive/something.php?dir=%3Bcat%20/etc/passwd</nowiki>
+Example: http://sensitive/something.php?dir=%3Bcat%20/etc/passwd
 If the applucation responds with the output of the /etc/passwd file then you know the attack has been successful.
@@ Line 152: / Line 152: @@
 http://example.com/index.php?file=http://192.168.0.2:9080
-| Example || Example
+| When the analysis is performed with a Gray Box approach, testers have to follow the same methodology as in Black Box Testing. However, since they can review the source code, it is possible to search the input vectors (stage (a) of the testing) more easily and accurately. During a source code review, they can use simple tools (such as the grep command) to search for one or more common patterns within the application code: inclusion functions/methods, filesystem operations, and so on.
 |-
+|
@@ Line 169: / Line 180: @@
 * Sensitive Information Disclosure
 | Since LFI occurs when paths passed to "include" statements are not properly sanitized, in a blackbox testing approach, we should look for scripts which take filenames as parameters.
 Consider the following example:
@@ Line 190: / Line 202: @@
 <code>user2:x:501:501::/home/user2:/bin/bash</code>
-| Example || Example
+| Very often, even when such vulnerability exists, its exploitation is a bit more complex. Consider the following piece of code:
 |-
+|
@@ Line 218: / Line 237: @@
 == Client Side Attacks ==
-These are attacks that target the user's browser as they require use action to be successful.
+These are attacks that require an action on the client (e.g. a user's browser) for the attack to be successful.
 {| class="wikitable"
 !Issue Name
@@ Line 240: / Line 259: @@
 When a web application is vulnerable to this type of attack, it will pass unvalidated input sent through requests back to the client. The common modus operandi of the attack includes a design step, in which the attacker creates and tests an offending URI, a social engineering step, in which she convinces her victims to load this URI on their browsers, and the eventual execution of the offending code using the victim's browser.
+|Testing for Reflected Cross Site Scripting involves injecting javascript into parameters in a web request and checking if the script is rendered as part of the response.
-−
+For a full list of the type of requests and techniques please see: [[XSS Filter Evasion Cheat Sheet|https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet]]
 |-
+|
@@ Line 257: / Line 284: @@
 * Directed delivery of browser-based exploits
 * Other malicious activities
+|
-−
+If a feature echos user supplied data without encoding, then the data can be interpreted as code in HTML.
 |-
+|
@@ Line 268: / Line 307: @@
 There have been very few papers published on this topic and, as such, very little standardization of its meaning and formalized testing exists.
+|Due to their nature, DOM-based XSS vulnerabilities can be executed in many instances without the server being able to determine what is actually being executed. This may make many of the general XSS filtering and detection techniques impotent to such attacks.
-−
+The first hypothetical example uses the following client side code:
 |-
+|