- Security is a fundamental topic when creating sustainable software.
- Protect your users, your organization or even yourself in mainly two ways:
- Protect their personal data
- Protect the devices they use with your service. An insecure application can serve as an attack-vector where you expose your users to external threats.
- Why does all this matter?
- A good developer
- securely handle users' information
- protects their users
- A good developer
- How is it present in Web Applications?
- Many different forms that can be categorized into two areas.
- Server-side security - Threats to the server-environment (Database injection, HTTP header configuration)
- Client-side security - Threats to the client-environment (XSS, CSRF)
- Many different forms that can be categorized into two areas.
The goal of this section is to give an overview of some of the most common threats on the web platform and will...
- Show how various threats can arise.
- Let you think like an attacker to exploit them.
- And most importantly - teach you how to protect your websites and applications.
Note: As a developer it's important to use your knowledge responsibly. The techniques you will learn in this section are shown in a safe, legal environment with the intention to make you understand an attackers mindset only so you can learn how to protect your websites and applications.
- This challenge explains why raw user input can't be trusted with a small example.
- TODO: better suggestion for example?
- Form asking for number
- Calculate
number * 5and display it back on the page (as text) - Ask the camper to start by entering a valid number and watch the result.
- Then ask the camper to enter invalid input (a random string for example) to see what happens when the app processes unexpected data.
This is an harmless example but it shows the principle - a developer can never trust the user to enter valid information. All input has to be verified in order to avoid bugs - and in the worst cases - security flaws.
There are two common methods (or are there more???) of verifying user input:
- Validation - checks if input meets a set of criteria.
- Sanitation - modifies input to make sure it's valid.
**Note: For these input verification challenges - let campers improve upon a single app, step by step.
App idea:
- Campers submit data to a signup form (for an event, since we need much input information) with 5-8 inputs
- Display the submitted information back to the user**
- Type checking
- Validate that a number is of a certain size.
- Type checking.
- Validate length of a string.
- Sanitation - modifies input to make sure it's valid.
Conclusion: Never trust raw user input - You can only trust user input after verifying it using multiple methods.
Resources:
- Simple search app with a vulnerable search-field.
- The app will run as if it's a full stack app when it's in fact just emulated in the browser.
- "client" for the search app implemented using the seed-code campers can see and modify.
- "server" implemented as a few functions available in the background but not directly visible to the camper
- Let the app have an emulated URL-bar to show the URL for the current page. For example:
epic-search.com/?q=<what the user searches for>. When this field is focused and enter is pressed, trigger the search-function just as if the main search-field was submitted. (This functionality is used for the later challenges)
- User enters query
- Query "parsed" in a fake back-end
- Result shown on screen: "Couldn't find any results for . Please try entering something else."
Cross Site Scripting (XSS) is one of the most common vulnerabilities on the web that lets an attacker execute malicious JS in the context of your website or application. It's mainly (or what's the other ways) introduced through unvalidated and unsanitized user input. A good start to preventing this type of attack is to always validate and sanitize user input before further use in your application.
Try searching for something in this example app. Notice how it displays your query in the results-view.
Now try searching for "<b>".
Notice how the result doesn't show your query but how the text after where your query should have been is bold.
This behavior might seem strange at first, but if we take a closer look at the search app's JavaScript, we find the line X (to be replaced when seed-code is completed). The search app takes the search query and injects it back into the HTML-document without verifying the content of the string it's injecting. The browser then tries to interpret the query string as if it's HTML and since it in this case finds an opening <b>-tag, the text will be bold.
Verify that the camper searches for:
- Any string
<b>
Note: This challenge requires the user to first complete the challenge and then continue exploring why the solution works.
In the previous example, you saw how the search app neither validates nor sanitizes the query-string before further using it in the app. This is a very risky behavior since the query may consist of any information that when injected will be parsed as HTML. Since the <b>-tag worked, why not try something more expressive? See if you can enter a <script>-tag and execute the alert-function to show a message in the browser.
TODO: continue clarifying instructions - especially the end.
As an attacker, your goal with an XSS-attack is to execute your JS in the same context as the target application. This is to give your script access to internal variables and functions. To enter your scripts, try using various input fields in the application. Most input fields will sanitize HTML and prevent you from entering the <script>-element you need to perform your attack. But since the input accepted the <b>-element earlier, we know that this field is vulnerable. Sometimes these vulnerable fields blindly accept <script>s and execute them.
- Create a custom wrapper for
alertto detect when it's triggered by a camper's code.
- The search app should
alerta message - Enter a script to make the search app
alerta message
Sanitize the input from the search field to prevent an attacker from entering HTML to your page.
In the previous challenge we experienced a basic form of XSS - a vulnerability where an attacker enters a script through some kind of user input (in this case a search-field) in order to execute it in the victim's browser.
Now we've seen why this search app is vulnerable and how an attacker can exploit it. This means we're ready to learn how to prevent this type of attack.
The fundamental thing is to always verify user input before it's processed in your application.
TODO: How to actually prevent this XSS-attack
- Sanitize the input string. Turn it into text safe to display on the webpage.
Note: This is a non-persistent attack since it only occurs for the user accessing the link. A persistent attack would
This is the follow-up from the previous challenge where we're exploring how user input sometimes not only comes from the webpage's various inputs. from the URL-bar.
In the previous challenges we saw how a single input field can allow an attacker to run their own JS. Although in this case the script was pretty harmless, a malicious script in a real application could easily steal cookies, modify the DOM or steal the user's information.
In this challenge, we'll continue to exploit vulnerabilities in this search app.
Think like an attacker. What ways can you enter input to the app. The input field was a straightforward way and since there aren't more inputs it's easy to think that this app now is secure.
How could you execute a script in another browser? A hint: look at the challenge title.
The challenge title is giving the answer away, maybe keep it as a tip
But the XSS-attacks doesn't only come from the webpage itself. Sometimes they even come from the browser's URL-bar.
This vulnerability seems to cause the same effect as the first vulnerability we patched up, but if we analyze it not only running the code in the attacker's browser. Since it's
- Ideally, users would use one unique password per service is way too much to be remembered.
- Password managers can ease the burden on users and let them just remember a single, strong password.
A typical "safe" password that has Mixed case, special characters, punctuation and numbers is not safe because users can't remember them and they have low entropy - meaning they are easy for a computer to brute-force or even guess. A strong password uses that also is easier to remember could be a sentence created out of completely random words.
Password Strength: https://www.explainxkcd.com/wiki/index.php/936:_Password_Strength
A crazy idea is to create a small JS-app where campers get to read about how for example a 2FA SSO works in the challenge description and then implement it in the challenge's template code. For example a signin-form in one div could be the "app / website" and a simulated "mobile phone" in another div could recieve a text-message to show how the authentication works in practice
TODO: Practical challenges for this? Maybe a simulated full-stack environment, maybe add this to a full stack project with an actual server environment.
We can also add to this course an introduction to password strength for general knowledge, because it's an important topic, but there are no other courses to put this in.