whoami

whoami

• Andrea Ida Malkah Klaura (if you need a legal name)
• jackie (in almost all other cases)
• Pronouns:
  • she/her in binary gender space
  • ze/hir in the wider multiverse
• Working mostly as open source engineer @ dieAngewandte
  • focus: backend with Python/Django and DevOps-y stuff
• Also trying to clone myself to do:
  • teaching web-based game prototyping and machine learning @ dieAngewandte
  • and feminist technoscience (studies) @ TU Wien
  • some side web projects for NGOs (mostly WordPress based)
  • organising feminist linux meetups and other community stuff
• More details on tantemalkah.at

some security basics

disclaimer

this is a very boiled down version of what you can find in the docs of the
Hack the heck out of this website! course, created together with Melanie Hosinner for the ditact women's IT-studies.

Terminology

• Key goals in infosec (the CIA triad)
  • Confidentiality
  • Integrity
  • Availability
• Access control
  • Identification
  • Authentication
  • Authorization
• What to look out for
  • Vulnerability
  • Exploit (special case: zero day 👿)

where do vulnerabilities come from?

• faulty/buggy/insecure code
• faulty/insecure use of code
• faulty/insecure/missing systematic approach to application development

the making of a vulnerability

...just some examples...

• in planning & design desicions:
  • trusting the user('s browser)
  • using outdated or self-coded encryption algorithms and insecure protocols
• while coding:
  • incomplete or missing input validation and output sanitization
  • insecure methods and queries to access a database
  • parsing user provided files (including configs from admins) without precautions
  • hardcoding credentials
• at run-time:
  • debugging mode in production systems

Remember: There is no "100% secure"!

web servers & web applications

speaking HTTP

• web clients request websites from web servers through HTTP
• a text-based, state-less protocol
• should be used with TLS anywhere -> HTTPS
• the browser does a lot of automagic stuff to display a web-site

🍪🍪🍪 Cookies 🍪👿🍪

• used for lots of questionable stuff
• but also because HTTP is state-less, e.g. to remember logged in users
• Part of a server response:

  
                    Set-Cookie: sessionToken=abcdef01234567890; Expires=Tue, 31 Aug 2021 12:34:56 GMT
                    Set-Cookie: foo=bar
                    Set-Cookie: chocolate=good
                    Set-Cookie: raisins=evil
                  

• Part of subsequent client requests:

  
                    Cookie: sessionToken=abcdef01234567890; foo=bar; chocolate=good; raisins=evil;
                  

What happens when I visit a website?

excerpt from Sending Passwords on Postcards, recording available on YouTube

1. I enter https://diebin.at into my browser and hit return
2. My browser asks the DNS server "What's the IP address of diebin.at?" and waits for a response - "Hey there, it's: 176.9.22.182!".
3. My browser sends a first HTTP request packet through the internet to the IP address 176.9.22.182
4. The webserver running on 176.9.22.182 receives the request and sends the website of "diebin.at" as a HTTP response.
   (one or more response packets are sent, depending on the size of the webservers reply)
5. My computers receives all the packets, assembles them according to TCP/IP protocol, and hands them to my webbrowser
6. My browser shows me the response in the form of a website

wait, wait! is that all?

• My browser requests all the images used in the HTML page that was just loaded
• My browser requests all the CSS files that are used to style my HTML page
• My browser requests all the JS files that are used to make my HTML page nicely interactive
• ... and potentially lots more of (auto)magic stuff ✨🪄✨

web sites vs. web applications

• mostly static hyperlinked content vs. highly interactive programme accessible through a web browser

two common vulnerabilities

Cross Site Scripting (XSS)

• tricking the web app to include JS code into the HTML output
• imagine a normal greeting:

  
                    
  Hello Mafalda, how are you?
                  

• What if the user did not just type "Mafalda" when asked for their name?

                
Hello Mafalda<script>alert('eeeevil!')</script>, how are you?
              

SQL injection (SQLi)

• tricking the web server to include SQL code in a database query
• imagine a query for a user that just has logged in:

  
                    SELECT * FROM users WHERE id = "mafalda";
                  

• What if the user did not just type mafalda when asked for their username?
• Let's assume they typed mafalda" OR 1 = 1; --

  
                    SELECT * FROM users WHERE id = "mafalda" OR 1 = 1; --";
                  

• 
  (Source: https://xkcd.com/327/ , under CC BY-NC 2.5 license)
  Or in the style of Li'l Bobby Tables:
  mafalda"; DROP TABLE users; --

... in action

• spinning up DVWA and OWASP Juice Shop with docker
• testing out some (simple) XSS & SQLi

demo.mp4 (~22min, 72MB)

Update 2024-03-10:
The open port mapping I mention in the video is meanwhile fixed for the OWASP Juice Shop.
I opened an issue, and they fixed it within a few days. 💜

Update 2024-03-13:
Now also fixed for the DVWA. I created a PR today, and it was merged within an hour. 💜💜

stats & context

OWASP Top 10

• https://owasp.org/www-project-top-ten/
• THE authoritative survey on vulnerability prevalences
• by the Open Worldwide Application Security Project
• 2017: Injection on place 1, XSS on place 7
• 2021: Injection (including XSS) on place 3
• 2025: "planning to announce the release [...] in the first half of 2025"

Example: WordPress

Source: The Wordfence 2023 State of WordPress Security Report

• Top 5 vulns disclosed in 2023:
  1. XSS (1963 cases reported)
  2. CSRF (1098 cases reported)
  3. Missing Authorization and Authorization bypass (885 cases reported)
  4. SQLi (279 cases reported)
  5. Information Disclosure (98 cases reported)

Update 2024 basically the same, just more of it:
2024 Annual WordPress Security Report by Wordfence

Important: most vulns come from plugins, very few in WordPress core

takeaways

for devs

• always validate (user) input
• always sanitize (the final HTML) output
• always use prepared statements or go for ORMs!
• don't do everything from scratch, use frameworks!
  • and pleeeeease update them in time!
• I know, I know, there is no 100% in security, but:
  if you make exceptions from above rules, you really need to know what you are doing!
• nag your higher-ups about secure coding workshops and a proper SDLC

a note on updates

this one also goes out to ops and management

references

• Hack the heck out of this website! (course docs by Melanie & me)
• Tanya Janca: SheHacksPurple YouTube channel
• Sonya Moisset: Open Source Software Security Handbook
• Megan Kaczanowski:
  • What is Cross Site Scripting? How to Protect against XSS Attacks
  • SQL Injection Tutorial - What is SQL Injection and How to Prevent it

events

• ditact women's IT studies - 25. Aug. - 5. Sep. 2025 (including my web app sec course)