6. Web Security
W EB SEC U R I TY
Web Security
Br o w s e r Se c u r i t y
1
• Many attacks today exploits browser vulnerabilities.
• Browsers d o not subject to perimeter protection.
• Browsers are complex
• have many extensions
• run downloaded c o d e
• Important transactions are conducted over the
browsers.
2
• Browser sends requests
• May reveal private information (in forms, cookies)
• Browser receives information, c o d e
• May corrupt state by running unsafe c o d e
request
Browser
OS
Hardware
reply
Web
site
Network
3
• Source: Statista
4
5
• Plug-ins:
• Adobe Acrobat, Flash, Apple QuickTime, etc.
• Extensions.
• Active Code:
• ActiveX
• JavaScript
6
§ Mobile code is any program, application, or content capable of movement
while embedded in an email, document or website
1.
Sandboxing
• C ode executed in browser has only restricted access to OS,
network
2.
Isolation: the same-origin principle
• Only the site that stores some information in the browser
may later read or modify that information (or depend on it
in any way).
3.
Establish trust in the c o d e
• c o d e digitally signed
7
• Examine c o d e before executing
• Performs critical tests
• Interpret c o d e and trap risky operations
• Run-time tests
• Security manager applies local access policy
• Security manager policy based on
• Site that supplied the c o d e
• C ode signing – who signed it?
8
Web Security
U n d e r st a n d i n g W e b A p p l i c a t i o n s
9
• HTTP is a stateless protocol.
• Hosts d o not need to retain information about users
between requests
• Web applications must use alternative methods to
track the user's progress from p a g e to p a g e
• sending and receiving cookies
• server side sessions, hidden variables a n d URL encoded
parameters (such as
/index.php?session_id=some_unique_session_code).
10
• File created by a browser to store information on the
client’s computer.
• Can b e read a n d written entirely on client side using
Javascript.
• Used for authenticating, tracking, a n d maintaining
specific information about user
• Security aspects
• Data may b e sensitive (security!)
• May b e used to gather information about specific users
(privacy!).
11
Browser
Enters form data
Stores cookie
Browser
Server
Requests cookie
Returns data
Server
12
• Cookie Same-origin ownership.
• Once a cookie is saved on your computer, only the Web
site that created the cookie c a n read it.
• Variations
• Temporary cookies
• Stored until you quit your browser
• Persistent cookies
• Remain until deleted or expire
• Third-party cookies
• Originates on or sent to a w e b site other than the one that
provided the current page
13
• Get a p a g e from merchant.com
• Contains <img src=http://doubleclick.com/advt.gif>
• Image fetched from DoubleClick.com
• DoubleClick knows IP address and p a g e you were looking at.
• DoubleClick sends back a suitable advertisement
• Stores a cookie that identifies "you" at DoubleClick
• Next time you get p a g e with a doubleclick.com image
• Your DoubleClick cookie is sent back to DoubleClick
• DoubleClick could maintain the set of sites you viewed
• Send back targeted advertising (and a new cookie)
• Cooperating sites
• Can pass information to DoubleClick in URL, etc.
14
• Cookies maintain record of your browsing habits
• Cookie stores information as set of name/value pairs
• May include any information a w e b site knows about you
• Sites track your activity from multiple visits to site
• Sites c a n share this information (e.g., DoubleClick).
15
• DoNotTrack (donottrack.us):
• Do Not Track is a technology and policy proposal that
enables users to opt out of tracking by websites they d o not
visit, including:
• analytics services,
• advertising networks,
• and social platforms.
16
Web Security
Sa m e Or i g i n Pol i c y a n d Sc r i p t i n g
17
• Web pages (HTML) c a n e m b e d dynamic contents
(code) that c a n executed on the browser
• Script are powerful:
• host access
• read / write local files
• w e b p a g e resources
• cookies
• Domain Object Model (DOM) objects.
18
<html>
…
<P>
<script>
var num1, num2, sum
num1 = prompt("Enter first number")
num2 = prompt("Enter second number")
sum = parseInt(num1) + parseInt(num2)
alert("Sum = " + sum)
</script>
…
</html>
19
• The basic security model enforced in the browser
• Web users visits multiple websites simultaneously
• SoP isolates the scripts and resources downloaded
from different origin
• bank.com vs. evil.org
• Origin = domain name + protocol + port
• All three must b e equal for origin to b e considered the same
20
• Limitations if site hosts unrelated pages
• Example: Web server often hosts sites for unrelated parties
• http://www.example.com/account/
• http://www.example.com/otheraccount/
• Same-origin policy, allows script on one p a g e to access
properties of document from another
• Can b e bypassed in Cross-Site-Scripting attacks
22
• Recall the basics
• scripts e m b e d d e d in w e b pages run in browsers
• scripts c a n access cookies
• get private information
• a n d manipulate DOM objects
• controls what users see
• scripts controlled by the same-origin policy
• Why would XSS occur?
• Web applications often take user inputs a n d use them as
part of w e b p a g e (these inputs c a n have scripts).
23
1. Everyone c a n post comments, which will be
displayed to everyone who view the post
2. Attacker posts a malicious comment that includes
scripts (which reads local authentication
credentials and send of to the attacker)
3. Anyone who view the post c a n have local
authentication cookies stolen
24
25
• In MySpace.com users c a n post HTML on their pages
• MySpace.com ensures HTML contains no
<script>, <body>, onclick, <a href=javascript://>
• However, attacker find out that a way to include Javascript
within CSS tags:
<div style=“background:url(‘javascript:alert(1)’)”>
And c a n hide “javascript” as “java\nscript”
• With careful javascript hacking:
• Samy’s worm: infects anyone who visits an infected MySpace
p a g e – a n d adds Samy as a friend.
• Samy h a d millions of friends within 24 hours.
26
• Input validation
• Escaping and filtering
• Eliminating script
27
• Main problem:
• Input checking is difficult – many ways to inject scripts into
HTML.
• Preprocess input from user before echoing it
• PHP: htmlspecialchars(string)
& → &amp;
" → &quot;
< → &lt;
> → &gt;
' → &#039;
• htmlspecialchars(
"<a href='test'>Test</a>",
ENT_QUOTES);
Outputs:
&lt;a href=&#039;test&#039;&gt;Test&lt;/a&gt;
28
• Also known as one click attack or session riding.
• Transmits unauthorized commands from a user who
has logged in to a website from another website.
29
• Example:
• User logs in to bank.com.
• Session cookie remains in browser state
• Then user visits another site containing:
<form name=F action=http://bank.com/BillPay.php>
<input name=recipient value=badguy> …
<script> document.F.submit(); </script>
• Browser sends user auth cookie with request
• Transaction will b e fulfilled
• Problem:
• browser is a confused deputy.
30
31
Web Security
SQ L In j e c t i o n
32
Phonebook Record Manager
Username
John
Password
open_sesame
Display
Delete
SELECT * FROM
phonebook WHERE
username =
‘John’ AND password =
‘open_sesame’
John’s phonebook
entries are displayed
Submit
Application Server
Web browser
User Input
Web Page
Query
Database
Result Set
33
Phonebook Record Manager
Username
John’ OR 1=1 --
Password
not needed
Display
Delete
Submit
SELECT * FROM phonebook
WHERE username = ‘John’
OR 1=1 --AND password =
‘not needed’
All phonebook entries
are displayed
Application Server
Web browser
User Input
Web Page
Query
Database
Result Set
34
35
• SQL queries c a n b e constructed by arbitrary
sequences of programming constructs that involve
string operations
• Concatenation, substring ….
• Such construct also involve (untrusted) user inputs
• Inputs should b e mere “ d a ta ” , but in case of SQL results in
“code”.
36
• Prepared Statements:
• PREPARE stmt_name FROM " SELECT * FROM phonebook
WHERE username = ? AND password = ?”
• Separates query structure from data
• Statements are NOT parsed for every user input
37
0
