The document outlines various web vulnerabilities including SQL injections, cross-site scripting (XSS), and cross-site request forgery (CSRF), providing definitions, defenses, and further reading resources for each. It emphasizes preventive measures such as validating input, using parameterized queries, and implementing strong password policies to mitigate these threats. Additionally, it covers best practices in session management and the importance of secure authentication methods.

1. Web vulnerabilities
July 28, 2017
Evo Summer Python Lab

2. Why is it important?
http://www.northhighland.com/-/media/POV_Pyramid_Graphic-03.png

3. Agenda
SQL Injections
Cross-site scripting (XSS)
Cross-site request forgery (CSRF)
Brute-force attacks
Misc

4. SQL Injection
https://xkcd.com/327/

5. SQL Injection – Definition
A SQL injection attack consists of insertion or "injection" of a SQL
query via the input data from the client to the application.
When exploited, allows attacker to
●
read sensitive data
●
modify database data
●
execute administration operations on db
https://www.owasp.org/index.php/SQL_Injection

6. SQL Injection – Defense
Do not construct SQL queries by concatenating strings
Do not construct SQL queries using formatted strings
Use parametrized queries (prepared statements)
Avoid using raw SQL. Especially with user input
Validate what users input

7. SQL Injection – Should you care about it?
https://i.kinja-img.com/gawker-media/imag
e/upload/18mpenleoksq8jpg.jpghttps://beta.companieshouse.gov.uk/compa
ny/10542519

8. SQL Injection – Further reading
●
https://www.owasp.org/index.php/SQL_Injection
●
http://bobby-tables.com/
●
http://www.unixwiz.net/techtips/sql-injection.html
●
http://www.websec.ca/kb/sql_injection

9. XSS
Cross-site scripting (XSS) is a type of computer security
vulnerability typically found in web applications. XSS enables
attackers to inject client-side scripts into web pages viewed by
other users.
https://en.wikipedia.org/wiki/Cross-site_scripting

10. XSS – Types
●
Reflected – malicious code retrieved with request and executed
on page. Not persistent.
●
Stored – malicious code is put into server by attacker and then
executed on the web page. Persistent.
●
DOM-Based – the entire tainted data flow from source to sink
takes place in the browser, i.e., the source of the data is in the
DOM, the sink is also in the DOM, and the data flow never leaves
the browser.

11. XSS – Defense
●
Validate user input
●
Escape data before display
●
Avoid using eval, document.write or innerHtml
●
Apply CSP (Content Security Policy) https://www.w3.org/TR/CSP/
●
Use X-XSS-Protection header for older browsers
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-X
SS-Protection
●
Use HttpOnly cookies https://www.owasp.org/index.php/HttpOnly

12. XSS – Further reading
●
https://www.google.de/intl/lt/about/appsecurity/learning/xss/
●
https://xss-game.appspot.com
●
https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)
●
http://www.webappsec.org/projects/articles/071105.shtml
●
https://www.owasp.org/index.php/DOM_based_XSS_Prevention_
Cheat_Sheet

13. CSRF
Type of attack that occurs when a malicious web site, email, blog,
instant message, or program causes a user’s web browser to
perform an unwanted action on a trusted site for which the user is
currently authenticated.
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet

14. CSRF – How it works?
https://www.incapsula.com/images/illustrations/web-app-security-mini-site/csrf-cross-site-request
-forgery.png

15. CSRF – Defense
●
Check standard headers to verify the request is same origin
●
Check CSRF token
●
Only include the CSRF token in POST requests
●
Prevent XSS
●
Require User Interaction
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet

16. CSRF – Further reading
●
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_
(CSRF)
●
https://www.owasp.org/index.php/SameSite
●
http://www.cgisecurity.com/csrf-faq.html
●
https://betterexplained.com/articles/gmail-contacts-flaw-overvi
ew-and-suggestions/

17. Bute-force attacks
https://regmedia.co.uk/2014/08/01/bruteforce111.jpg

18. Brute-force attack – Definition
Brute-force attacks work by calculating every possible
combination that could make up a password and testing it to see
if it is the correct password.
As the password’s length increases, the amount of time, on
average, to find the correct password increases exponentially.
https://en.wikipedia.org/wiki/Brute-force_attack

19. Brute-force – Defense
●
Monitor activity for anomalies
●
Limit requests (Throttling)
●
Enforce users to use strong passwords
●
Block accounts which are being brute-forced
●
Use CAPTCHA
●
Use 2-Factor authentication

20. Brute-force – Further reading
●
https://www.owasp.org/index.php/Testing_for_Brute_Force_(OW
ASP-AT-004)
●
http://resources.infosecinstitute.com/popular-tools-for-brute-for
ce-attacks/

21. Misc – Verifying authorization
●
Always verify if user is authorized to perform the action
●
Hiding action buttons with CSS or disabling them is not sufficient
●
Not rendering action buttons at all is not sufficient

22. Misc – Passwords
●
Passwords should not be stored as plain text. Do not store
passwords at all.
●
Just hashing password with SHA-512 is not sufficient.
●
Use unique salt to prevent rainbow-table lookups
●
Use bcrypt, PBKDF2, scrypt or Argon2 for hashing
●
Constant-time hashing prevents timing attacks
https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet
https://en.wikipedia.org/wiki/Bcrypt
https://security.stackexchange.com/questions/133239/what-is-the-specific-reason-to-
prefer-bcrypt-or-pbkdf2-over-sha256-crypt-in-pass

23. Misc – Certificates and pinning
●
Use HTTPS to prevent sniffing attacks
●
HTTPS is not good enough – adjust it with certificate pinning
●
Sometimes even pinned certificate is not enough
https://doesmysiteneedhttps.com/
https://www.owasp.org/index.php/Pinning_Cheat_Sheet
https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning
https://www.cossacklabs.com/avoid-ssl-for-your-next-app.html

24. Misc – Token-based auth
●
Prefer token-based auth over login/password
●
Just a random string
●
Tokens are often less expensive to verify than passwords
●
Tokens can be easily revoked if compromised
https://www.w3.org/2001/sw/Europe/events/foaf-galway/papers/fp/token_based_authentication/
https://jwt.io/
https://security.stackexchange.com/a/63438

25. Misc – Sessions
●
Make sure session keys are completely random
●
Encrypt session data if stored on client
●
Make session lifetime as short as possible
●
Make sure you can revoke session anytime
https://www.owasp.org/index.php/Session_Management_Cheat_Sheet
http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/

26. Misc – Validate and escape
●
Always validate all user input to prevent XSS attacks or just mess
in database
●
Always escape user-generated output, no matter how good is
your input validation – this will prevent even old data (which
bypassed validation) to harm your users
http://www.securityweek.com/oauth-20-vulnerability-leads-account-takeover

27. Misc – Further reading
●
https://martinfowler.com/articles/web-security-basics.html
●
https://github.com/shieldfy/API-Security-Checklist
●
https://github.com/FallibleInc/security-guide-for-developers
●
http://www.dvwa.co.uk/
●
https://security.stackexchange.com/
●
https://www.soapui.org/security-testing/security-scans/xml-bomb.html
●
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

28. http://pre14.deviantart.net/967d/th/pre/i/2017/025/9/9/trust_no_one___bill_cipher_by_lucybeliebe
r-dawojus.png

29. Questions?