### Attacks 👻 We will cover: 😈 Cross Site Scripting (XSS) 😈 Cross Site Request Forgery (CSRF) 😈 How we can defend against each of them? --- ### What is Cross Site Scripting (XSS)?  ---  > Jamis Charles UI Engineer at PayPal --- 🛑 💉 XSS is a security vulnerability in web applications where... --- The attacker sneaks some malicious JavaScript (usually via a <script> tag) into your HTML which is then executed... --- Imagine you receive an 📧 asking you to login into your bank....  --- After login you're instructed to click on this link... ``` https://yourBankWebsite.com/account?id=<script>[maliciousCodeHere]</script> ``` --- This malicious code injected into the HTML can run in the broswer 😈 💉 --- Because you are logged in it can steal your session token (and your session) with the 🏦. It can browse your accounts (the bank thinks it's you!) and possibly transfer 💵 😱 --- In this instance we have a user input (name) as part of our generated url  --- This isn't a problem until somebody inserts a <script></script> instead 🚨  ---  --- There are 2 main types of XSS attack: 1. Reflected/Stored XSS 👾 2. DOM-based XSS 👾 --- Reflected and Stored XSS are attacks injected on the **server side** while DOM based XSS is **client (browser) side** --- All of this code originates on the server, which means it is the application owner's (that's us!) responsibility to make it safe from XSS, regardless of the type 🔥 Also, XSS attacks always execute in the browser. --- What can we do?  --- In short sanitise our inputs 🧼... --- #### CSRFs Cross-Site Request Forgery  --- - Relies on your browser keeping & automatically sending all ur cookies. (ie the way you are encouraged to use the internet.) - Sends a malicious POST request to an external website - Rather than XSS (bad link to a real website) the CSRF is found on a bad (*or compromised*) website --- Example of an easily exploitable form ```html < form method="POST" action="twitter.com/sendtweet"> <input type="text" name="tweet_content" value="I love tweeting!"> <input type=’submit’ value="Submit"> </form> ``` (your cookies are used to send it from your account) --- A malicious coder could make a button on their website send something like this ```html < form method="POST" action="twitter.com/sendtweet"> <input type="text" name="tweet_content" value="I love arson!"> <input type="submit" value="Submit"> </form> ``` --- And make it invisible ```html style="display:none" ``` --- and run as soon as you enter a website ```html <script> document.querySelector('form').submit()<script> ``` --- Disaster!🔥🔥🔥  --- This is a simplification, and it's likely that they'll use AJAX (Asynchronous JavaScript and XML) as opposed to html Ultimately you aren't responsible for what other people put on their websites, but **you are responsible for how your site handles data**. It is possible to make your site CSRF-resistant. --- ### Attacks and how to defend <iframe src="https://giphy.com/embed/jlviGaszl51C0" width="480" height="221" frameBorder="0" class="giphy-embed" allowFullScreen></iframe> 1. The attacks from CSRF are still very common and hard to avoid, uber, starbucks and other websites are still susceptible * step one logout of the website after using it. so the session ends --- * Use a Javascript blocker: * By disabling Javascript on your browser or email client, you essentially render auto-submit forms useless. This way, CSRF attacks would become harder since attackers would have to trick you into manually submitting the form instead. * use a different browser --- Treat any user input as unsafe. Sanitizing at the templating layer ``` name %>by default because it sanitizes by encoding any html tags, so any <script> tag will show up as &lt;script&gt; in the html and <script> ``` --- Sanitizing at the storage layer ``` <script>[maliciousCode]</script> ``` --- ### xss 1. Filter input on arrival. At the point where user input is received, filter as strictly as possible based on what is expected or valid input. 1. Specifying a charset. First of all, ensure that your web page specifies the UTF-8 charset 2. HTML escaping. Keep in mind that you need to HTML-escape all user input. This includes replacing < with &lt;, > with &gt;, & with &amp; --- 1. Other types of escaping. You still, however, need to be careful to never insert user input as an unquoted attribute or an attribute interpreted as JavaScript (e.g. onload or onmouseover) 2. Validating URLs and CSS values. The same goes for URLs of links and images (without validating based on approved prefixes) 3. Not allowing user-provided HTML. Do not allow user-provided HTML if you have the option. 4. Preventing DOM-based XSS. ---