Web Hacking 101 🥷

Codegarden 2025

<workshop>

Course Website

These slides and the exercises for this workshop can be found here:

https://101.umbsec.icu/

Disclaimer

This workshop will introduce you to hacking tools and techniques that could be
used to cause real damage to web applications and infrastructure.

How you use this information is ultimately up to you, but be aware that
attempting to hack systems you do not own is illegal.

Get explicit consent from the organisation that owns a system before attacking it.

$ whoami

  • Steven Harland / stvnhrlnd
  • Technical Director @ Etive Mòr
    • Software development, climate tech, sustainability, security
  • Umbraco Community Security and Privacy Team member 🔒
  • Umbraco developer since 2013
  • Offsensive security consultant (penetration tester)

Agenda

  • 6 exercises, each covering different tools, techniques, or vulnerabilities.
  • I'll demo each exercise, then allow some time for you to try it out yourself.
  • We'll discuss what we found and possible fixes/mitigations.
  • Break after ~42 mins ☕

Scope

The Scumm Bar 🏴‍☠️

Capture the Flag Challenge

  • Sign up here: https://ctf.umbsec.icu/
    • Registration code: CG2025
  • Watch out for flags while hacking around the application.
    • These are unique and look like this: flag{C0d3g4rd3n_2025}
  • Submit the flags to get points and top the leaderboard.
  • The CTF server is not in scope, do not attack it.

Exercise 00: System Setup

We will make use of the following tools in this workshop:

All tools are free and available on Kali, a Linux distribution for penetration testing and ethical hacking.

See the System Setup exercise for instructions.

Exercise 01: Passive Recon

  • Before we start actively attacking an application we need to perform information gathering or reconnaissance.
  • We start with passive recon (stealthy).
    • Open-source intelligence or OSINT.
  • In the next exercise we will look at active recon (noisy).

Examples

  • Publicly available sources of information.
  • Company website(s), blogs, forums.
  • Domain Name System (DNS) records.
  • Social media profiles and posts.
  • Public government data (e.g., UK Companies House).
  • Open source code repositories
  • etc.

What to look out for

  • Employee names and email addresses.
    • These are potential members or users of the target application/site.
  • Software libraries and web frameworks being used.
    • Often revealed in HTML source code or HTTP response headers.
  • Interesting functionality that we might want to attack.
  • Anything that will help us to narrow our focus and increase our chances
    of a successful attack.

Note taking

  • Write down anything and everything you find interesting.
  • Seemingly insignificant details can turn out to be extremely important.
  • Use whatever note taking tool you like, just make sure you do it.
    • You will thank yourself when you come to write the report.
  • Keep lists of potential usernames/emails/passwords in simple text files.
    • These will be useful later.

Demo

Exercise 01: Passive Recon

Exercise 02: Active Recon

  • Uses automated tools and scanners.
  • Sends lots of requests to the target application.
  • Carries risk of being detected, blocked, or bringing down the site.

Techniques

  • Directory busting (dirbusting) and fuzzing.
    • Used to find hidden pages, API endpoints, exposed configuration files, database backups, etc.
  • Vulnerability scanning.
    • Used to find known vulnerabilities (CVEs) and misconfigurations.
    • Watch out for false positives - manually verify all findings.
    • A vuln scan is not a pentest.

Demo

Exercise 02: Active Recon

Mitigations

  • Ensure that you are not revealing more information than is necessary about
    your organisation, employees, the software you use, etc.
    • But always assume an attacker will get information from somewhere, even
      if not directly from your website/application.
  • Use a web application firewall (WAF) to block automated scans when they occur.
    • This will slow down attacks, but won't prevent them completely.

Exercise 03: Burp Repeater

  • Essential tool for manipulating and replaying web requests.
  • Web app pentesters spend a lot of time in Repeater.
  • In this exercise we will use it to manipulate a hidden form input on the member registration form to escalate our privileges.

Demo

Exercise 03: Burp Repeater

Code Review

A fix for the privilege escalation issue on the registration form has been
published to the branch bugfix/member-privesc. You can see a comparison of the code here:

https://github.com/stvnhrlnd/DVUA/compare/main...bugfix/member-privesc

In this case I've simply put a check in to ensure the role is "Standard" before proceeding.

However, this is a contrived example and the role should probably not come from
a hidden input anyway. The main point of this was to demonstrate Burp Repeater.

Exercise 04: User Enumeration

  • A vulnerability that allows an attacker to determine whether a user exists in
    an application or system.
  • Often found on login, registration, and forgotten password forms.

Techniques

  • Analyse the HTTP responses of forms when supplied with:
    • A valid/known email address.
    • An invalid/non-existant email address.
  • Look for differences in:
    • Error messages.
    • HTTP status codes.
    • Response content length.
    • Response timing.

In the Wild

Example - Before Patch

A Burp Intruder attack showing backoffice login for a several usernames. Highlighted in the middle is a request that took longer than the rest which indicated a vaid user.

Example - Before Patch

A Burp Intruder attack showing backoffice login for a several usernames. Highlighted in the middle is the same user as before but this time the response timing is similar to the others.

Demo

Exercise 04: User Enumeration

Mitigations

  • Ensure that your applications return the same response whether or not a user
    exists in the system:
    • Same error messages.
    • Same HTTP status code.
    • Same response length.
    • Similar response times.
  • Use a web application firewall (WAF) to block automated user enumeration attempts.

Code Review

A fix for the user enumeration issue on the login form has been published to
the branch bugfix/user-enumeration. You can see a comparison of the code here:

https://github.com/stvnhrlnd/DVUA/compare/main...bugfix/user-enumeration

In this instance we have simply modified the error message returned by the
application so that it says Invalid username or password, and therefore
doesn't reveal if the member exists or not.

Aside

  • Even if your application has no user enumeration vulns, assume that an attacker will still be able to construct a list of potential users using OSINT or passive techniques.
  • There is not much point in removing your organisation's "team" page from your website when employee details can often be gathered from LinkedIn for example.

Exercise 05: Password Guessing

  • An attack which involves trying to guess a user's password in order to gain access to their account.
  • We can automate this with Burp Intruder.
  • We will look at an online password guessing attack.
    • Sends one HTTP request per attempt so it is important we choose a good word list.

Word Lists

  • There are many sources online, for example: SecLists
  • Choose a list relevant to the system you are attacking.
    • SecLists has common default passwords for different situations, as well as leaked passwors from the dark web.
  • Refine your lists so that they adhere to the password policy of the application you are attacking.
    • Less requests, less noise, less chance of lockout or denial of service.

Password Policy

You may have noticed this on the member registration form:

An error message on the member registration form that states "The password must be at least 10 characters long".

Knowing this, we can narrow down our password lists to those with 10 characters
or more.

If there are other complexity requirements, we can account for these too.
For example, if there is a requirement for numbers in the password, we can remove those without.

Demo

Exercise 05: Password Guessing

Mitigations

  • Enforce strong passwords (duh).
  • Use multi-factor authentication.
    • Mitigates weak passwords by giving attackers another hurdle to overcome.
  • Account lockouts.
    • On by default for Umbraco members and users (5 attempts).
  • WAF to rate limit or block brute force attempts.

Exercise 06: Cross-Site Scripting

  • A vulnerability that allows an attacker to inject arbitrary HTML or JavaScript code onto a web page.
    • Malicious code is executed in the victim's web browser.
  • Occurs when:
    • User inputs have not been properly validated or sanitised.
    • User inputs are rendered on an HTML page without encoding them first.

In the Wild

Example - Umbraco

A screenshot of the Umbraco "Publish with descendants" dialog. In the background the node name can be seen to contain an XSS payload. A JavaScript alert dialog overlays the page with the text "1".

Example - Clean Starter Kit

The Clean Starter Kit viewed on localhost. The parameter in the query string of the search page contains an HTML tag with the code . A JavaScript alert dialog is shown overlaying the window with the text "hax".

Demo

Exercise 06: Cross-Site Scripting

Mitigations

  • Input validation
  • Input sanitisation
  • Output encoding
  • HttpOnly cookies
  • Content Security Policy

Input Validation

  • Reject inputs containing dangerous characters.
  • Stops potentially malicious values from being processed and/or stored by your application.
  • Should be first thing a controller action/API does.

Input Sanitisation

  • Accept the input but attempt to strip out dangerous characters.
  • Use an XSS sanitisation library to strip out potentially malicious code before storing it.
  • Do not write your own sanitisation code.
    • There are many, many weird and wonderful XSS payloads.
    • XSS sanitisation libraries (e.g., DOMPurify) will cover far more cases than you could hope to.

Output Encoding

  • Prevent raw HTML/JavaScript code from being interpreted as such by the browser and executed.
  • Often done by default by many web frameworks but can be bypassed to render raw HTML.
    • Razor: @Html.Raw(something)
    • React: <div dangerouslySetInnerHTML={something} />

HttpOnly

  • A flag when applied to cookies prevents them from being accessed by JavaScript code.
  • Applied by default to Umbraco member and user cookies.
    • Has been disabled on DVUA for demonstration purposes.
  • When set against a cookie, document.cookie in JavaScript will not contain the cookie.

Content Security Policy (CSP)

  • Defined in an HTTP header or meta tag.
  • Tells browsers where it's safe to load resources from.
  • Can prevent cross-domain requests.
    • CSP could be used to prevent the cookie being sent to Interactsh in the exercise.

Code Review

A fix for the XSS issue in the product reviews feature has been published to
the branch bugfix/xss. You can see a comparison of the code here:

https://github.com/stvnhrlnd/DVUA/compare/main...bugfix/xss

We have added some server-side validation which uses the HtmlSanitizer
package to check if the comment contains malicious code and if so, return an error.

The fix also re-enables the HttpOnly flag for the member cookies.

Recap

In this workshop we covered:

  • Information gathering/recon (passive and active).
  • User enumeration vulnerabilities.
  • Password guessing attacks.
  • Cross-site scripting attacks.
  • Using some of the most essential Burp Suite tools (Proxy, Repeater, Intruder).

Additional Resources

This workshop is only the tip of the iceberg when it comes to web security. There are many more tools, techniques, and vulnerabilities than we could cover.

I recommend the following resources for going further on your security journey:

</workshop>