Use a separator (;) to inject an OS command in the Domain Name
- +
{domain name}; {OS command}
e.g. google.com; pwd
+ Take a look at the GET method in a1_lookup.php (line 51). User input is stored the variable $domain and echoed back to the user (this is also vulnerable to XSS as the HTML control characters are not encoded when displayed). The user input is appended to the whois 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 input sanitization and output encoding. OWASP has a concise summary of Injection Attacks here. +
++ The code in check_bots.php simply checks to see that the redirect location string of the captcha form contains 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 here. +
+ diff --git a/src/Final/a2.html b/src/Final/a2.html index 52f7fe4..bd06aec 100755 --- a/src/Final/a2.html +++ b/src/Final/a2.html @@ -95,7 +95,11 @@
sessionID cookie is a SHA1 hash of the username. Replace SHA1(user1) in the cookie by SHA1(user2) to authenticate as user2.
i.e. sessionID=a1881c06eec96db9901c7bbfe41c42a3f08e9cb4
+ Take a look at the GET method in a2.php (line 51) and the if method in user_details.php 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 here. 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 here. +
diff --git a/src/Final/a5.html b/src/Final/a5.html index e980a00..630b324 100755 --- a/src/Final/a5.html +++ b/src/Final/a5.html @@ -90,6 +90,11 @@+ The include method at a5.php (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 here. +
+ diff --git a/src/Final/a6.html b/src/Final/a6.html index 6238c58..999a401 100755 --- a/src/Final/a6.html +++ b/src/Final/a6.html @@ -159,6 +159,11 @@+ The javascript if method at a6.html (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 here. +
+ diff --git a/src/Final/a7.html b/src/Final/a7.html index d30f7e5..932a4c2 100755 --- a/src/Final/a7.html +++ b/src/Final/a7.html @@ -94,7 +94,11 @@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.
- + ++ 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 function_AC.php 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 here. +
diff --git a/src/Final/a9.html b/src/Final/a9.html index 4c7acfd..4629175 100755 --- a/src/Final/a9.html +++ b/src/Final/a9.html @@ -91,6 +91,11 @@+ 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 here. +
+ diff --git a/src/Final/reflected_xss.php b/src/Final/reflected_xss.php index d01253d..089fa56 100755 --- a/src/Final/reflected_xss.php +++ b/src/Final/reflected_xss.php @@ -80,7 +80,15 @@Enter any malicious JavaScript code. e.g., <script>window.location.href = "http://opendns.com";</script>
- + ++ The user name parameter at lucky.php + (line 51) is echoed back to the page without being sanitized and is vulnerable to XSS. This can be + prevented by encoding output.. OWASP has a concise summary of XSS + here. +
+ diff --git a/src/Final/stored.html b/src/Final/stored.html index cc820fc..0760c1b 100755 --- a/src/Final/stored.html +++ b/src/Final/stored.html @@ -108,7 +108,13 @@Enter any malicious javascript code. e.g., <script>window.location.href = "http://opendns.com";</script>
- + ++ This page is slightly better in that it performs some client side validation of user input (see the validateForm function in stored.html). 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 store_users.php 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 fetch_users.php (line 83) file returns. The fetch_users does no output encoding or replacing of HTML control characters. XSS can be mitigated by sanitizing user input server side and encoding output. OWASP has a concise summary of XSS here. +
+ diff --git a/src/Final/view_email.php b/src/Final/view_email.php index 3845cc2..5207785 100755 --- a/src/Final/view_email.php +++ b/src/Final/view_email.php @@ -142,6 +142,14 @@ function showForm2(){'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).
+ ++ The save action at line 106 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 here.