WebFund 2016W Lecture 22 - Revision history

Zero: Minor details.

2016-04-11T17:24:27Z

Minor details.

← Older revision		Revision as of 17:24, 11 April 2016
Line 322:		Line 322:
	***e.g., Java applets, Flash, Silverlight		***e.g., Java applets, Flash, Silverlight
	*And, what about all those other languages?		*And, what about all those other languages?
	**C,C++?		**C, C++?
	**How about games?		**How about games?
	***Unreal runs in a web page because there’s WebGL which is pretty fast (WebGL is a subset of ~~openGL~~)		***[https://www.unrealengine.com/html5/ Unreal Engine runs in a web page] because there’s WebGL which is pretty fast (WebGL is a subset of OpenGL)
	*So why can’t we compile code and have it run in the browser?		*So why can’t we compile code and have it run in the browser?
	*Two old solutions:		*Two old solutions:

Zero: Added PNaCl vs NaCl.

2016-04-11T17:21:27Z

Added PNaCl vs NaCl.

← Older revision		Revision as of 17:21, 11 April 2016
Line 327:		Line 327:
	*So why can’t we compile code and have it run in the browser?		*So why can’t we compile code and have it run in the browser?
	*Two old solutions:		*Two old solutions:
	**NaCl (Google)		**PNaCl/NaCl (Google)
	***Native Client is a sandbox for running compiled C and C++ code in the browser efficiently and securely, independent of the user’s operating system		***Portable Native Client (PNaCl) is a sandbox for running compiled C and C++ code in the browser efficiently and securely, independent of the user’s operating system or architecture (e.g. x86 or ARM). (NaCl is more or less the same except it only can be used by extensions/plugins and depends on the user's CPU architecture; you can only use an x86 NaCl app on x86.)
	**asm.js (Mozilla)		**asm.js (Mozilla)
	***This uses a compiler that takes arbitrary programs and compiles them to JavaScript		***This uses a compiler that takes arbitrary programs and compiles them to JavaScript

Zero: I believe this is the correct URL?

2016-04-11T17:14:11Z

I believe this is the correct URL?

← Older revision		Revision as of 17:14, 11 April 2016
Line 249:		Line 249:
	*DNS has almost no security		*DNS has almost no security
	*There is DNSSEC but nobody uses it, yet at least		*There is DNSSEC but nobody uses it, yet at least
	**If you want to know more about this, you can find the article on [usenix.org usenix.org]		**If you want to know more about this, you can find the article on [https://www.usenix.org/blog/security-symposium-talk-measuring-practical-impact-dnssec-deployment usenix.org]
	*You can better protect cookies by using HSTS		*You can better protect cookies by using HSTS
	**This forces HTTPS everywhere on a page/domain		**This forces HTTPS everywhere on a page/domain

Zero: Typo.

2016-04-11T17:11:03Z

Typo.

← Older revision		Revision as of 17:11, 11 April 2016
Line 206:		Line 206:
	**Someone inserts malicious media/device		**Someone inserts malicious media/device
	**Parking lot flashdrive attack (a flashdrive is left in a parking lot for someone to pick up and plug in)		**Parking lot flashdrive attack (a flashdrive is left in a parking lot for someone to pick up and plug in)
	**(solution: epoxy, no one can ~~pug~~ anything in)		**(solution: epoxy, no one can plug anything in)
	**Electromagnetic emissions		**Electromagnetic emissions
	***(solution: live in a Faraday cage, almost completely isolated from any EM transmission)		***(solution: live in a Faraday cage, almost completely isolated from any EM transmission)

LeeCroft: /* And now the web */

2016-04-04T03:06:12Z

And now the web

← Older revision		Revision as of 03:06, 4 April 2016
Line 256:		Line 256:
	**Because HTTP was supposed to be stateless		**Because HTTP was supposed to be stateless
	**The cookies are used instead to create a state between the client and server		**The cookies are used instead to create a state between the client and server

	~~<br>~~

	*If we could get past these problems, would we have proper security?		*If we could get past these problems, would we have proper security?
	**Definitely not		**Definitely not

LeeCroft: /* And now the web */

2016-04-04T03:05:52Z

And now the web

← Older revision		Revision as of 03:05, 4 April 2016
Line 240:		Line 240:
	**There are different levels of insider attacks. Just because of you have account on gmail doesn’t mean you have access to the inside system. You don’t have full access, but you have some access, that is potentially dangerous.		**There are different levels of insider attacks. Just because of you have account on gmail doesn’t mean you have access to the inside system. You don’t have full access, but you have some access, that is potentially dangerous.
	*So from this we can see that web security is going to be hard		*So from this we can see that web security is going to be hard
			*The other half of the nightmare is the browser
	~~<br>~~

	*The other half of the nightmare: the browser
	*Ideally, to secure systems you isolate components		*Ideally, to secure systems you isolate components
	**Build big walls		**Build big walls

LeeCroft: /* Computer in an isolated room */

2016-04-04T03:05:26Z

Computer in an isolated room

← Older revision		Revision as of 03:05, 4 April 2016
Line 207:		Line 207:
	**Parking lot flashdrive attack (a flashdrive is left in a parking lot for someone to pick up and plug in)		**Parking lot flashdrive attack (a flashdrive is left in a parking lot for someone to pick up and plug in)
	**(solution: epoxy, no one can pug anything in)		**(solution: epoxy, no one can pug anything in)
	**~~electromagnetic~~ emissions		**Electromagnetic emissions
	***(solution: live in a Faraday cage, almost completely isolated from any EM transmission)		***(solution: live in a Faraday cage, almost completely isolated from any EM transmission)

LeeCroft at 03:05, 4 April 2016

2016-04-04T03:05:01Z

Show changes

Soma: Created page with "==Video== The video for the lecture given on March 31, 2016 [http://homeostasis.scs.carleton.ca/~soma/webfund-2016w/lectures/comp2406-2016w-lec22-31Mar2016.mp4 is now availab..."

2016-03-31T21:10:40Z

Created page with "==Video== The video for the lecture given on March 31, 2016 [http://homeostasis.scs.carleton.ca/~soma/webfund-2016w/lectures/comp2406-2016w-lec22-31Mar2016.mp4 is now availab..."

New page

==Video==

The video for the lecture given on March 31, 2016 [http://homeostasis.scs.carleton.ca/~soma/webfund-2016w/lectures/comp2406-2016w-lec22-31Mar2016.mp4 is now available].

==Notes==

===In Class===

<pre>
Lecture 22
------------
Web Security

Security in isolated systems
- no networking

What is the threat model?

Threat model
- what attacks are you trying to defend against
- what attacks are you NOT trying to defend against

Computer in an isolated room
- ignore physical attacks, e.g. sledgehammers

How to compromise this computer?
- someone bad starts typing
- someone inserts malicious media/device
- parking lot flashdrive attack
(solution: epoxy)
- electromagnetic emissions
(live in a faraday cage)

Computer on a network
- all local attacks
- attacker can send arbitrary network data to system
- attacker can listen in on network traffic
- attacker can change outgoing traffic

Basic defense: network crypto
- encrypt to hide, sign data to protect integrity,
verify authenticity

Who will access?
- authenticated, authorized users
- unauthorized individuals/systems
- attackers (can be either of the above)

How can an attacker be "authorized"?
- social engineering
(can you please reset my password?)
- brute force (try all the passwords)
- technical compromise of credentials (keylogger)
- authorized user turns/is malicious
(insider attack)

And now the web

Who can access your application?
- ANYBODY
- for public web apps, ANYBODY is an authorized user

So just from this we can see that web security is going
to be hard.

The other half of the nightmare: the browser

Ideally, to secure systems you isolate components
- build big walls

Your web browser has walls between pages...but there are
BIG HOLES (on purpose)

- cookies, in particular, are shared
- this is bad because the scope of cookies is
determined by DNS (domain name system)

DNS has almost no security
- there is DNSSEC but nobody uses it, yet at least

You can better protect cookies by using HSTS
- force HTTPS everywhere on a page/domain
- protects against mixes of http/https content and
downgrade attacks

Why do we have cookies in the first place?
- because HTTP was supposed to be stateless

Also...

Cross-site Scripting (XSS) attacks
- not necessarily cross-site, not necesarily scripting
- "web injection attacks"
- see anywhere attacker can inject content into a page
- (ads)
- comments
- social media
- "user-generated content"
- failure to sanitize untrusted input that is inserted
into a web page
(adding a comment to a page)
- otherwise, you can insert arbitrary HTML, CSS,
and JavaScript into the page

Cross-site request forgery
- makes use of cookies automatically being sent
to domain, no matter where the link came from
- can stop using tokens in URLs, or checking
Referer/Origin headers (and a few other ways)

Same-origin policy
- data should only be loaded from the originating
server
- but, you can load almost anything else from
anywhere
- images
- sound
- javascript

So what about JSON?
- when you load it with AJAX, you have same origin
policy
- but if you just treated it as a script...
- and what if you were logged in
- bank sending data as JSON

JSON files are valid JavaScript but they don't specify
the name to give to the data structure
- so you can't access it, unless

To build an object, you have to call the object's
constructor
- why not replace the constructor with our own method?
e.g., override Array
- this is solved in regular browsers for JSON by
only using a clean JavaScript environment for
JSON.parse()

This doesn't help you for code, but who cares about
code, right?
- many websites dynamically generate JavaScript and put
personal information into it

Solution? Don't mix code and data!

WebAssembly
-----------

* Many, many people hate JavaScript
* Lots of code that isn't JavaScript
* But people want everything to run on the web
in a browser

Past efforts at having alternative languages all
had a basic problem
- they couldn't see the DOM
- e.g., Java applets, Flash, Silverlight

And, what about all those other languages?
- C, C++??!
- how about games?

Unreal runs in a web page
- there's WebGL which is pretty fast

So, why can't we compile code and have it run in the
browser?

Two old solutions:
- NaCl (Google)
- asm.js (Mozilla)

They joined up and are now making WebAssembly

This will be good for functionality and bad for
security.
- security won't go well because code isn't
designed for the web
- but it will be cool to play games in a browser at
full speed :-)
</pre>