Add brief explanations to each vulnerability

src/Final/a1.html

@@ -84,17 +84,22 @@ <h5>A1 : Injection</h5>
 							<P>
 							Use a separator (;) to inject an OS command in the Domain Name
 							</P>
-							
+
 							</DIV></li>
 
 							<li><H5 style="cursor: pointer" onclick="toggleBlock(this, 'solution');"> Solution </H5>
 							<DIV id="solution" style="display:none">
 							<P>
 							{domain name}; {OS command}<br> e.g. &nbsp;  google.com; pwd
 							</P>
-
+
+							<h4>Why?</h4>
+							<p style="text-align:left">
+								Take a look at the GET method in <a href="https://github.com/opendns/Security_Ninjas_AppSec_Training/blob/master/src/Final/a1_lookup.php#L51">a1_lookup.php</a> (line 51). User input is stored the variable <i>$domain</i> and echoed back to the user (this is also vulnerable to <a href="https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29">XSS</a> as the HTML control characters are not encoded when displayed). The user input is appended to the <i>whois</i> command without any sanitization (such as allowing only alphanumeric values and periods). Finally, that command is executed directly with the permissions of the web server. Whatever the web server has access to, a user now does, too (e.g. configuration files, world readable files, system info). The key lessons here are <a href="https://www.owasp.org/index.php/Data_Validation">input sanitization</a> and <a href="https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet">output encoding</a>. OWASP has a concise summary of Injection Attacks <a href="https://www.owasp.org/index.php/Top_10_2013-A1-Injection">here</a>.
+							</p>
+
 							</DIV></li>
-							
+
 							</ul>
 							</div>
 						</div>

src/Final/a10.html

@@ -96,6 +96,11 @@ <h5>A10 : Unvalidated Redirects and Forwards</h5>
 							Edit redirect_to to opendns.com.{bad URL} <br> e.g. opendns.com.internetbadguys.com
 							</P>
 
+							<h4>Why?</h4>
+							<p style="text-align:left">
+								The code in <a href="https://github.com/opendns/Security_Ninjas_AppSec_Training/blob/master/src/Final/check_bots.php#L12">check_bots.php</a> simply checks to see that the redirect location string of the captcha form <i>contains</i> opendns.com. As the Solution above points out, a malicious user could simply add a subdomain of opendns.com to their own domain, and the validation would succeed. Using burp, modify the redirect parameter to "google.com/?q=opendns.com" and see for yourself! OWASP has a concise summary of Unvalidated Redirects and Forwards <a href="https://www.owasp.org/index.php/Top_10_2013-A10-Unvalidated_Redirects_and_Forwards">here</a>.
+							</p>
+
 							</DIV></li>
 
 							</ul>

src/Final/a2.html

@@ -95,7 +95,11 @@ <h5>A2 : Broken Authentication and Session Management</h5>
 							<P>
 							sessionID cookie is a SHA1 hash of the username. Replace SHA1(user1) in the cookie by SHA1(user2) to authenticate as user2. <br>i.e.  sessionID=a1881c06eec96db9901c7bbfe41c42a3f08e9cb4
 							</P>
-
+
+							<h4>Why?</h4>
+							<p style="text-align:left">
+								Take a look at the GET method in <a href="https://github.com/opendns/Security_Ninjas_AppSec_Training/blob/master/src/Final/a2.php#L57">a2.php</a> (line 51) and the if method in <a href="https://github.com/opendns/Security_Ninjas_AppSec_Training/blob/master/src/Final/user_details.php#L57">user_details.php</a> at line 57. When the credentials are verified, the session ID cookie is set to a trivially guessable value of a hash of the user name. When the user_details.php page is viewed, it checks the sessionID value and displays a users data based off that value. As the sessionID can be controlled by the user and is easily guessable, private information is disclosed. An excellent primer on Session Management is <a href="https://www.owasp.org/index.php/Session_Management_Cheat_Sheet">here</a>. Session IDs should be long enough to prevent brute force attacks, and random enough to prevent guessing attacks. OWASP has a concise summary of Broken Authentication and Session Management <a href="https://www.owasp.org/index.php/Top_10_2013-A2-Broken_Authentication_and_Session_Management">here</a>.
+							</p>
 							</DIV></li>
 
 							</ul>

src/Final/a5.html

@@ -90,6 +90,11 @@ <h5>A5 : Security Misconfiguration</h5>
 							Fetch sensitive files by changing the fname parameter e.g., fname=../../../../../etc/passwd
 							</P>
 
+							<h4>Why?</h4>
+							<p style="text-align:left">
+								The include method at <a href="https://github.com/opendns/Security_Ninjas_AppSec_Training/blob/master/src/Final/a5.php#L52">a5.php</a> (line 52) takes in user input without any sort of sanitization and displays that file to the user. Any file the web server has permission to view, the end user now does as well. In addition to hardening server and environment configurations, ensure that user input is not used without sanitization and or specify allowed include files. OWASP has a concise summary of Security Misconfigurations <a href="https://www.owasp.org/index.php/Top_10_2013-A5-Security_Misconfiguration">here</a>.
+							</p>
+
 							</DIV></li>
 
 							</ul>

src/Final/a6.html

@@ -159,6 +159,11 @@ <h5>A6 : Sensitive Data Exposure</h5><br>
 							oneteamonedream
 							</P>
 
+							<h4>Why?</h4>
+							<p style="text-align:left">
+								The javascript if method at <a href="https://github.com/opendns/Security_Ninjas_AppSec_Training/blob/master/src/Final/a6.html#L38">a6.html</a> (line 52) plainly displays sensitive information on the client. Ensure that sensitive data is not transmitted in clear text and that anything client side is fair game for manipulation. OWASP has a concise summary of Sensitive Data Exposure <a href="https://www.owasp.org/index.php/Top_10_2013-A6-Sensitive_Data_Exposure">here</a>.
+							</p>
+
 							</DIV></li>
 
 							</ul>

src/Final/a7.html

@@ -94,7 +94,11 @@ <h5>A7 : Missing Function Level Access Control</h5>
 							<P>
 							Remove the style 'display:none' in the div with id 'admin_view' to make the hidden div visible. As this function lacks server side access control, you would be able to exploit this functionality.
 							</P>
-
+
+							<h4>Why?</h4>
+							<p style="text-align:left">
+								Using your browser's developer tools you should be able to display the div as described above as well as change the POST parameters to make yourself admin. The code in <a href="https://github.com/opendns/Security_Ninjas_AppSec_Training/blob/master/src/Final/function_AC.php#L49">function_AC.php</a> simply checks to see whether the client supplied value of is_admin is true before it carries out its operation. Access control should take a default deny policy and users should not be able to influence their authorization levels through client side parameters. OWASP has a concise summary of Function Level Access Control <a href="https://www.owasp.org/index.php/Top_10_2013-A7-Missing_Function_Level_Access_Control">here</a>.
+							</p>
 							</DIV></li>
 
 							</ul>

src/Final/a9.html

@@ -91,6 +91,11 @@ <h5>A9 : Using Components with Known Vulnerabilities</h5>
 							Append "#&lt;img src=x onerror=alert(1)&gt;" at the end of the URL. Note that this proof of concept attack might not pop up an alert if your browser has anti-XSS protections. You might need to refresh the page or wait for a few moments for the pop up to actually show.
 							</P>
 
+							<h4>Why?</h4>
+							<p style="text-align:left">
+								Check out the Minded Security blog post above in Hint 2 for a good explanation on why this occurs. OWASP has a concise summary of Using Components with known vulnerabilities <a href="https://www.owasp.org/index.php/Top_10_2013-A9-Using_Components_with_Known_Vulnerabilities">here</a>.
+							</p>
+
 							</DIV></li>
 
 							</ul>

src/Final/reflected_xss.php

@@ -80,7 +80,15 @@
 							<P>
 							Enter any malicious JavaScript code. e.g., &lt;script&gt;window.location.href = &quot;http://opendns.com&quot;;&lt;/script&gt;
 							</P>
-
+
+							<h4>Why?</h4>
+							<p style="text-align:left">
+								The user name parameter at <a href="https://github.com/opendns/Security_Ninjas_AppSec_Training/blob/master/src/Final/lucky.php#L51">lucky.php</a> 
+								(line 51) is echoed back to the page without being sanitized and is vulnerable to <a href="https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29">XSS</a>. This can be 
+								prevented by <a href="https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet">encoding output.</a>. OWASP has a concise summary of XSS 
+								<a href="https://www.owasp.org/index.php/Top_10_2013-A3-Cross-Site_Scripting_%28XSS%29">here</a>.
+							</p>
+
 							</DIV></li>
 
 							</ul>

src/Final/stored.html

@@ -108,7 +108,13 @@ <h5>A3 : Stored Cross-Site Scripting (XSS)</h5>
 							<P>
 							Enter any malicious javascript code. e.g., &lt;script&gt;window.location.href = &quot;http://opendns.com&quot;;&lt;/script&gt;
 							</P>
-
+
+							<h4>Why?</h4>
+							<p style="text-align:left">
+								This page is slightly better in that it performs some client side validation of user input (see the validateForm function in <a href="https://github.com/opendns/Security_Ninjas_AppSec_Training/blob/master/src/Final/stored.html#L23">stored.html</a>). But remember that these checks are trivially defeated by disabling javascript or using a web proxy such as Burp Suite. The name and username parameters in the <a href="https://github.com/opendns/Security_Ninjas_AppSec_Training/blob/master/src/Final/store_users.php#L52">store_users.php</a> file (line 52) are written directly to the file comments.txt without sanitizing output against a whitelist server side.
+								These comments are echoed back from whatever the <a href="https://github.com/opendns/Security_Ninjas_AppSec_Training/blob/master/src/Final/fetch_users.php#L83">fetch_users.php</a> (line 83) file returns. The fetch_users does no output encoding or replacing of HTML control characters. XSS can be mitigated by <a href="https://www.owasp.org/index.php/Data_Validation">sanitizing user input</a> server side and <a href="https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet">encoding output</a>. OWASP has a concise summary of XSS <a href="https://www.owasp.org/index.php/Top_10_2013-A3-Cross-Site_Scripting_%28XSS%29">here</a>.
+							</p>
+
 							</DIV></li>
 
 							</ul>

src/Final/view_email.php

@@ -142,6 +142,14 @@ function showForm2(){
 							<P>
 							'update_email.php?new_email=user1@gmail.com&user=user1&Update=Save' is the relative URL and send it as a phishing link to user1 or embed it in a page and make user1 go to that page. If user1 is authenticated, the action would be executed (vice versa for user2). 
 							</P>
+
+							<h4>Why?</h4>
+							<p style="text-align:left">
+								The save action at <a href="https://github.com/opendns/Security_Ninjas_AppSec_Training/blob/master/src/Final/view_email.php#L106">line 106</a> of view_email.php 
+								allows a user to perform a sensitive function without ensuring it was created by the user themselves through the use of a unique token. Per the above Solution, 
+								a user could unknowingly have their email address updated by visiting a malicious site or clicking a malicious link. There are a number of framework level solutions
+								and libraries that help implement CSRF tokens to mitigate this risk.
+								OWASP has a concise summary of Cross Site Request Forgery <a href="https://www.owasp.org/index.php/Top_10_2013-A8-Cross-Site_Request_Forgery_%28CSRF%29">here</a>.							</p>
 
 							</DIV></li>