FCC InfoSec Curriculum Outline
The goal of this section is to give an overview of some of the most common threats on the web platform and will...
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.
number * 5
and display it back on the page (as text)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:
**Note: For these input verification challenges - let campers improve upon a single app, step by step.
App idea:
Conclusion: Never trust raw user input - You can only trust user input after verifying it using multiple methods.
Resources:
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)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:
<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.
alert
to detect when it's triggered by a camper's code.alert
a messagealert
a messageSanitize 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
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
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.