This document discusses common web application security vulnerabilities like SQL injection and insecure session management that can lead to data breaches. It provides examples of how vulnerabilities in user authentication and session handling can be exploited to compromise accounts or perform account takeovers. The key lessons are that all user input should be sanitized and parameterized queries used to prevent SQL injection. Session IDs also need to be unpredictable, time limited, and their transport secured to prevent session hijacking attacks. Secure development practices like least privilege access and secure coding guidelines are recommended to build applications securely.

1. Tales of modern day data breaches - a web
security guide for developers
Jaap Karan Singh
jaap@scw.io
Co-Founder & Chief Singh, Secure Code Warrior

2. > Today’s challenges with software security

3. Of data breaches caused by software
vulnerability ~ Verizon
21%
Source: Verizon, Data Breach Report, 2018 (but in there the last 10 years)

4. of newly scanned applications had SQL injections
over the past 5 yrs ~ Cisco
1 in 3
Source: Cybersecurity as a Growth Advantage, Cisco, 2016

5. > Data Breach #1: US Election Board Systems

6. Personal data of voters stolen by a teenager
SQL Injection
Understanding the data breach

7. Was it an Anonymous hacker lurking
in the shadows?
Script kiddie ALERT!
Freely available tools and scripts used for the attack

8. A user submits his
credentials using
POST parameters.
The parameters are appended
to a database query string that
is submitted to the database.
The session cookie is
returned to the browser;
the user is now logged in.
Client Web
Server
DB Server
John
Doe
Username: John, Password: Doe
SELECT * FROM Users
WHERE Username = “John”
AND Password = “Doe”
Scenario 1: Normal authentication workflow
The credentials are valid and
the appropriate record is
returned to the web server.
Understanding the security vulnerability

9. A user submits his
credentials using
POST parameters.
The parameters are appended
to a database query string that
is submitted to the database.
The session cookie is
returned to the browser;
the user is now logged in.
Client Web
Server
DB Server
John
Doe
Username: John, Password: Doe
SELECT * FROM Users
WHERE Username = “John”
AND Password = “Doe”
Returned 1 Row
(‘John’, ‘Doe’, ‘Admin’)
Set-cookie: sessionid=
FUHOJFB0I4BW121X7281
Scenario 1: Normal authentication workflow
The credentials are valid and
the appropriate record is
returned to the web server.
Understanding the security vulnerability

10. Understanding the security vulnerability
SELECT * FROM Users WHERE
Username = ‘admin’ AND
Password = ‘abc’ OR 1=1;Username: admin, Password: abc’ OR 1=1;
Web
Server
DB Server
admin
abc’ OR 1=1;
Scenario 2: Authentication bypass
The submitted input changes the
logic of the query. Because of the
always true condition, the
password condition will be
ignored!
The session cookie is
returned to the browser;
the attacker is now
logged in as
administrator.
The vulnerability is exploited
in order to gain control to an
account without providing a
valid password.
An attacker submits input
values that will take
advantage of the query.

11. Understanding the security vulnerability
SELECT * FROM Users WHERE
Username = ‘admin’ AND
Password = ‘abc’ OR 1=1;Username: admin, Password: abc’ OR 1=1;
Web
Server
DB Server
admin
Returned 1 Row
(‘admin’, ‘John’, ‘admin’)
Set-cookie: jsessionid=
FUHOJFB0I4BW121X7281
abc’ OR 1=1;
Scenario 2: Authentication bypass
The submitted input changes the
logic of the query. Because of the
always true condition, the
password condition will be
ignored!
The session cookie is
returned to the browser;
the attacker is now
logged in as
administrator.
The vulnerability is exploited
in order to gain control to an
account without providing a
valid password.
An attacker submits input
values that will take
advantage of the query.

12. Realising the impact
Altered data such as balance and transaction
information could cause repudiation issues.
System unavailability could cause
revenue and reputation loss.
Account and private data theft could
damage reputation and credibility,
causing customer and revenue loss.

13. Preventing the mistake
Never concatenate user-controllable input with application
SQL to form the query sent to the database.
Consider GET and POST parameters, Cookies and other HTTP headers.
Use parameterized queries.
All of the popular development frameworks provide support for
secure construction of database queries.
insert_user_query = "INSERT INTO users (name, age, gender) VALUES (“
+ request_user_name + “,” + request_user_age
+ “)";
insert_user = db.prepare(insert_user_query)
insert_user.execute()
insert_user = db.prepare "INSERT INTO users (name, age, gender) VALUES (?, ?)"
insert_user.execute(request_user_name, request_user_age)

14. Preventing the mistake
In addition, apply white-list validation on all user input.
Consider GET and POST parameters, Cookies and other HTTP headers.
Apply the least privilege principle on the database users.

15. How easy is it to exploit SQL injection?
Follow along on your computer and find out!

16. > Data Breach #2: Facebook Access Tokens

17. 50,000,000 accounts affected
Access tokens exposed that keep users logged into Facebook
Understanding the data breach

18. Do you have a login system in your applications?
cookies && sessions
Insecure Session Management

19. Understanding session management
What are cookies?
HTTP is a stateless protocol.
Cookies can be used to track a
user’s state by storing values
related to the user’s actions.
These cookie values are sent to
and from the server and are
stored in the client’s browser.
When are cookies used?
Cookies can be used to store an
online shopping cart or browsing
activities. Another usage are
authentication cookies, which
store the user’s session
information to determine
whether a user is logged in and
which privileges are assigned to
that user.
Set-cookie: user=johndoe
Cookie: user=johndoe
How are cookies protected?
Certain flags can be added when
setting a cookie to limit its usage:
• Secure – Avoid transmission
over an insecure channel.
• HttpOnly – Don’t let JavaScript
read cookie value.
• Domain – Set the domain for
which the cookie is available.
• Path – Set subfolders and
pages for which the cookie is
available.
• Expires – Determine when the
cookie should be deleted.

20. Understanding the security vulnerability
An attacker logs into a site.
The site uses a simple
increment to generate
session IDs.
The attacker, noticing the
predictability of the ID
generation, deduces new ID’s,
which he uses to browse back to
the site.
By being able to predict
session ID’s he is able to
impersonate the
authenticated user and is
allowed full access to the
user’s account.
After a few attempts, the attacker
finds a session ID that is associated
with another authenticated user.
Web
Application
Cookie:
sessionID=1234
Weak session token
generation
Authenticated
User

21. Understanding the security vulnerability
An attacker logs into a site.
The site uses a simple
increment to generate
session IDs.
The attacker, noticing the
predictability of the ID
generation, deduces new ID’s,
which he uses to browse back to
the site.
By being able to predict
session ID’s he is able to
impersonate the
authenticated user and is
allowed full access to the
user’s account.
After a few attempts, the attacker
finds a session ID that is associated
with another authenticated user.
Web
Application
Cookie:
sessionID=1235
Cookie:
sessionID=1234
Weak session token
generation
Authenticated
User

22. Understanding the security vulnerability
An attacker logs into a site.
The site uses a simple
increment to generate
session IDs.
The attacker, noticing the
predictability of the ID
generation, deduces new ID’s,
which he uses to browse back to
the site.
By being able to predict
session ID’s he is able to
impersonate the
authenticated user and is
allowed full access to the
user’s account.
After a few attempts, the attacker
finds a session ID that is associated
with another authenticated user.
Web
Application
Cookie:
sessionID=1235
Cookie:
sessionID=1234
Weak session token
generation
Cookie: sessionID=1234
Authenticated
User
Welcome ‘User’!

23. Understanding the security vulnerability
An attacker browses to a
site (without logging in)
and is assigned a session
ID. He wants to trick a
victim into using this same
session ID.
A link to the login page is sent to
the victim. The link contains the
session ID of the attacker. The
victim is tricked into clicking the
link.
The attacker resubmits a
request with the session ID
which is now associated with
the authenticated victim. He has
now access to the victim’s
account.
The victim logs in and,
because of weak session
management, is assigned the
session ID provided by the
attacker!
Web
Application
Session fixation
Set-Cookie: sessionID=E34G0JS
Cookie: sessionID=E34G0JS

24. Understanding the security vulnerability
Please update your password:
GET /login?SESSIONID=E34G0JS
An attacker browses to a
site (without logging in)
and is assigned a session
ID. He wants to trick a
victim into using this same
session ID.
A link to the login page is sent to
the victim. The link contains the
session ID of the attacker. The
victim is tricked into clicking the
link.
The attacker resubmits a
request with the session ID
which is now associated with
the authenticated victim. He has
now access to the victim’s
account.
The victim logs in and,
because of weak session
management, is assigned the
session ID provided by the
attacker!
Web
Application
Session fixation
Victim
Set-Cookie: sessionID=E34G0JS
Set-Cookie: sessionID=E34G0JS
Cookie: sessionID=E34G0JS
Cookie: sessionID=E34G0JS

25. Understanding the security vulnerability
Please update your password:
GET /login?SESSIONID=E34G0JS
An attacker browses to a
site (without logging in)
and is assigned a session
ID. He wants to trick a
victim into using this same
session ID.
A link to the login page is sent to
the victim. The link contains the
session ID of the attacker. The
victim is tricked into clicking the
link.
The attacker resubmits a
request with the session ID
which is now associated with
the authenticated victim. He has
now access to the victim’s
account.
The victim logs in and,
because of weak session
management, is assigned the
session ID provided by the
attacker!
Web
Application
Session fixation
Victim
Set-Cookie: sessionID=E34G0JS
Set-Cookie: sessionID=E34G0JS
Cookie: sessionID=E34G0JS
GET /profile?SESSIONID=E34G0JS
Welcome ‘Victim’
Cookie: sessionID=E34G0JS

26. Realizing the impact
Weak session management allows attacks on
the session ID. Having a user’s session ID is
basically the same as getting that user’s login
and password.
A stolen administrator account could lead to
disruption of the website, causing loss of customers
and revenue.
Due to account theft, sensitive end-user
(customer) data could be stolen, leading to
reputational damage and revenue loss

27. Preventing the mistake
Session ID properties must be secure.
Unpredictable, time limited, single session.
Use session management features provided by
your development framework.
Store sessions IDs in cookies.
Protect session cookies appropriately.
Expiry timestamp, path, secure flag, invalidate on logout.
Secure the transport layer.
See “Insufficient Transport Layer Protection”

28. How easy is it to exploit session
management vulnerabilities?
Follow along on your computer and find out!

29. > Lessons learnt

30. Secure coding commandments

31. Uplift your security game
Classroom training
eLearning

32. Play the long game
Dependency
management
Create secure coding
guidelines
Build relationship with
application security team
01 02 03

33. Are you ready to be a superhero?