SystemsSec 2016W Lecture 22 - Revision history

Hammadasad: /* */

2016-04-05T18:24:07Z

← Older revision		Revision as of 18:24, 5 April 2016
Line 4:		Line 4:
	*JavaScript Injection		*JavaScript Injection
	**Sebastian Lekies et al., ''[https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/lekies The Unexpected Dangers of Dynamic JavaScript]'' (USENIX Security 2015)		**Sebastian Lekies et al., ''[https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/lekies The Unexpected Dangers of Dynamic JavaScript]'' (USENIX Security 2015)
	== ==		==Notes==

	- Any attack on user space in Linux could work on Windows		- Any attack on user space in Linux could work on Windows
Line 10:		Line 10:
	- Azure is already multiplatform; allowing Linux applications to run on Windows.		- Azure is already multiplatform; allowing Linux applications to run on Windows.

	- Web Security Review:		===Web Security Review===
	- Questions to discuss:		- Questions to discuss:
	- What is the threat model of web security?		- What is the threat model of web security?
Line 31:		Line 31:
	- Web browsers weren't initially designed for a shared environment that executes a large variety of applications		- Web browsers weren't initially designed for a shared environment that executes a large variety of applications
	- Because of all the interactions the browser allows, it affects the security of everything in the infrastructure.		- Because of all the interactions the browser allows, it affects the security of everything in the infrastructure.
	- Cookies		===Cookies===
	- It's data that contains the state of the user or session		- It's data that contains the state of the user or session
	- Efforts to delete the cookies every so often can be useful, but can reduce security		- Efforts to delete the cookies every so often can be useful, but can reduce security
Line 51:		Line 51:
	- You can hijack cookies because you can mess with DNS		- You can hijack cookies because you can mess with DNS

	- Protocols		===Protocols===
	- Browsers don't distinguish well between HTTP and HTTPS, therefore not guaranteeing a secured connection over HTTPS.		- Browsers don't distinguish well between HTTP and HTTPS, therefore not guaranteeing a secured connection over HTTPS.
	- Why do we use cookies? Why do we authenticate tokens?		- Why do we use cookies? Why do we authenticate tokens?
Line 67:		Line 67:
	- Very easy to intercept (Man in the middle attack) instead of breaking encryption		- Very easy to intercept (Man in the middle attack) instead of breaking encryption

	-		===Some Types of Attacks===
	- Some Types of Attacks
	- Cross-Site Scripting (XSS)		- Cross-Site Scripting (XSS)
	- Untrusted data inserted into the page		- Untrusted data inserted into the page
Line 79:		Line 78:
	- You can override the array prototype methods to leak it		- You can override the array prototype methods to leak it
	- Doesn't work anymore, clean JS environment is used to parse the JSON		- Doesn't work anymore, clean JS environment is used to parse the JSON
	- Paper: The Unexpected Dangers of Dynamic JavaScript
			===Paper: The Unexpected Dangers of Dynamic JavaScript===
	- Paper is about loading JS script files from target websites into attacker's web application to gain access to sensitive data		- Paper is about loading JS script files from target websites into attacker's web application to gain access to sensitive data
	- Gain access to JS file by guessing location of the script		- Gain access to JS file by guessing location of the script
Line 85:		Line 85:
	- How to mitigate against it?		- How to mitigate against it?
	- Don't keep sensitive data in dynamic JS files, keep it in the static files		- Don't keep sensitive data in dynamic JS files, keep it in the static files
	- Paper: Cookies Lack Integrity: Real-World Implications
			===Paper: Cookies Lack Integrity: Real-World Implications===
	- In general, this paper is hard to keep track of		- In general, this paper is hard to keep track of
	- Web security in general, is very tough to handle in contrast to OS security where we have reference monitors and policies. Web security does contain similar elements, but they are scattered		- Web security in general, is very tough to handle in contrast to OS security where we have reference monitors and policies. Web security does contain similar elements, but they are scattered
	- The web is a bit is like a distributed OS in the sense that we know how to scale it, predict behavior, but don't have security guarantees		- The web is a bit is like a distributed OS in the sense that we know how to scale it, predict behavior, but don't have security guarantees
	- How to solve web security? How would you architect it?		===How to solve web security?===
			- How would you architect it?
	- Perhaps isolate applications to domains		- Perhaps isolate applications to domains
	- Have a trusted browser as the reference monitor		- Have a trusted browser as the reference monitor
Line 96:		Line 98:
	- Every website can reqest a particular running environment by using hashes.		- Every website can reqest a particular running environment by using hashes.
	- Secure web security would essentially break the entire revenue model of the web - advertising.		- Secure web security would essentially break the entire revenue model of the web - advertising.
	- ASM.JS		===ASM.JS===
	- A subset language of JS that allows arbitrary code to be compiled to JS with assembly-like speed.		- A subset language of JS that allows arbitrary code to be compiled to JS with assembly-like speed.
	- Still have all the protection that JS would have		- Still have all the protection that JS would have

Hammadasad at 18:11, 5 April 2016

2016-04-05T18:11:52Z

← Older revision		Revision as of 18:11, 5 April 2016
Line 1:		Line 1:
			==Topics and Readings==
			*Cookies And Integrity
			**Xiaofeng Zheng et al., ''[https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/zheng Cookies Lack Integrity: Real-World Implications]'' (USENIX Security 2015)
			*JavaScript Injection
			**Sebastian Lekies et al., ''[https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/lekies The Unexpected Dangers of Dynamic JavaScript]'' (USENIX Security 2015)
			== ==

	- Any attack on user space in Linux could work on Windows		- Any attack on user space in Linux could work on Windows
	- If we make it easy to run Android apps on Windows OS, who would want to develop windows applications?		- If we make it easy to run Android apps on Windows OS, who would want to develop windows applications?

Hammadasad: Created page with "- Any attack on user space in Linux could work on Windows - If we make it easy to run Android apps on Windows OS, who would want to develop windows applications? - Azure is al..."

2016-04-01T21:12:55Z

Created page with "- Any attack on user space in Linux could work on Windows - If we make it easy to run Android apps on Windows OS, who would want to develop windows applications? - Azure is al..."

New page

- Any attack on user space in Linux could work on Windows
- If we make it easy to run Android apps on Windows OS, who would want to develop windows applications?
- Azure is already multiplatform; allowing Linux applications to run on Windows.

- Web Security Review:
- Questions to discuss:
- What is the threat model of web security?
- Who is the attacker? The defender?
- What is happening?
- An example of the attacker targeting a user is phishing (taking credentials)
- An example of the attacker targeting a web server: sending random data/traffic (ie. comment spams)
- The attacker messes with the browser through the network connection and can then run arbitrary code inside the browser
- The browser contains tokens that help access information from the web server
- The purpose of getting access to a token – impersonation
- The web in general, has a lot of depth and richness, opening up vast amounts of vulnerabilities.
- The execution of the model is strange
- Where does the web application live?
- It doesn't just live in the browser, it consists of the entire web model/mesh
- It's distributed
- Not every entity of the model is trusted
- All these web applications are running on the same system, but each have API's that allow them to connect to the rest of the world
- The design of the model is convoluted
- Web security is complex because of web browsers
- Web browsers weren't initially designed for a shared environment that executes a large variety of applications
- Because of all the interactions the browser allows, it affects the security of everything in the infrastructure.
- Cookies
- It's data that contains the state of the user or session
- Efforts to delete the cookies every so often can be useful, but can reduce security
- Cookies are used to mark your browser as special or known
- Professor suggests using a different browser configuration for banking related activities
- Firefox allows you to setup different configurations through profiles, which have their own cookie stores, history, etc.
- Just because a browser, such as Chrome, is sandboxed, it doesn't mean that it's secure. Cookies stores are still shared
- Cookie stores are little file systems, but with not high integrity
- Cookies belong to domain names -> You can specific general domain names or specific routes
- Domain names can be bad if you're connecting to untrusted networks
- DNS is a distributed database for mapping host names to IP addresses
- Example:
- Accessing 'scs.carleton.ca'
- Find who has authority for 'ca' -> then for Carleton -> then for scs
- Going through different systems to find names, there's also no cryptographic protection against DNS (There are a lot of attacks that can fake it)
- Networks at Starbucks intercept the DNS. Splash page pops up when visiting a site. DNSSEC can be used to mitigate against it, but not used often.
- Everything depends on DNS. If tampered with, everything breaks.
- Cookies are insecure because DNS is insecure
- You can hijack cookies because you can mess with DNS

- Protocols
- Browsers don't distinguish well between HTTP and HTTPS, therefore not guaranteeing a secured connection over HTTPS.
- Why do we use cookies? Why do we authenticate tokens?
- HTTP was designed to be stateless, but we then wanted to have states
- Technical standards aren't always better. Ie. Local Storage for cookies
- You keep things secure by isolating them
- Lack of isolation for functional purposes – People want to do things
- HSTS
- Not really a new protocol
- Enforces access over HTTPS
- If not HTTPS, don't trust
- It's because some web applications use both HTTP and HTTPS. The HTTPS downgrades to HTTP. HSTS won't let it talk to the page.
- Downgrade attack:
- Connection isn't encrypted at all
- Very easy to intercept (Man in the middle attack) instead of breaking encryption

-
- Some Types of Attacks
- Cross-Site Scripting (XSS)
- Untrusted data inserted into the page
- Cross-Site Request Forgery (CSRF)
- Impersonation
- Sending unauthorized requests
- Using JSON to attack
- SOP not implemented for JSON markup files
- It executes into an object; you gain a reference to it
- You can override the array prototype methods to leak it
- Doesn't work anymore, clean JS environment is used to parse the JSON
- Paper: The Unexpected Dangers of Dynamic JavaScript
- Paper is about loading JS script files from target websites into attacker's web application to gain access to sensitive data
- Gain access to JS file by guessing location of the script
- Once the JS script file is loaded, properties of JS such as global variables, scoping, prototype inheritance with method overwriting can be used to access the sensitive data
- How to mitigate against it?
- Don't keep sensitive data in dynamic JS files, keep it in the static files
- Paper: Cookies Lack Integrity: Real-World Implications
- In general, this paper is hard to keep track of
- Web security in general, is very tough to handle in contrast to OS security where we have reference monitors and policies. Web security does contain similar elements, but they are scattered
- The web is a bit is like a distributed OS in the sense that we know how to scale it, predict behavior, but don't have security guarantees
- How to solve web security? How would you architect it?
- Perhaps isolate applications to domains
- Have a trusted browser as the reference monitor
- Make the browser as minimal as possible
- Get rid of the DOM and JS; instead have some mediary format
- Every website can reqest a particular running environment by using hashes.
- Secure web security would essentially break the entire revenue model of the web - advertising.
- ASM.JS
- A subset language of JS that allows arbitrary code to be compiled to JS with assembly-like speed.
- Still have all the protection that JS would have
- Problem:
- People would start running all kinds of code in the browser that isn't designed for the web
- Arbitrary environments
- Whole new class of exploits