and Web Applications 06 Secure Coding Alexandros Labrinidis - - PDF document
CS 1655 / Spring 2010 Secure Data Management and Web Applications 06 Secure Coding Alexandros Labrinidis University of Pittsburgh Secure Coding From: Secure Coding: Principles and Practices by Mark G. Graff & Kenneth R. Van Wyk
CS 1655 / Spring 2010 Alexandros Labrinidis, Univ. of Pittsburgh
2
From:
First chapter is available online:
CS 1655 / Spring 2010 Alexandros Labrinidis, Univ. of Pittsburgh
3
When:
Where:
What:
Why:
Real-life equivalent:
A calls B B hangs up A does not hang up Result: B’s phone is busy! (no longer the case :-)) CS 1655 / Spring 2010 Alexandros Labrinidis, Univ. of Pittsburgh
4
Someone discovers a security flaw Bad guys analyze info Good guys try to fix it Media take over… People get worried Panic responses (stop all email at a company) Patch is ready Technical-savvy folks apply patch Many people don’t apply patch Good guys look for related problems MUCH LATER, an exploit is released - those with patches
CS 1655 / Spring 2010 Alexandros Labrinidis, Univ. of Pittsburgh
5
Architectural-design level attacks:
Man-in-the-middle Race-condition Replay Sniffer Session hijacking Session killing CS 1655 / Spring 2010 Alexandros Labrinidis, Univ. of Pittsburgh
6
Implementation-level attacks
Buffer-overflow Back door attack Parsing error attack
CS 1655 / Spring 2010 Alexandros Labrinidis, Univ. of Pittsburgh
7
Operations-level attacks
Denial-of-service Default accounts Password cracking policies CS 1655 / Spring 2010 Alexandros Labrinidis, Univ. of Pittsburgh
8
Technical Factors
In other fields, the whole may be greater than the sum of its
Phsychological Factors
Decisions influenced by personal experiences Mental models (of what the program is doing) Ways of thinking about software
Real world factors
Production pressure Just secure enough The tragedy of the commons
CS 1655 / Spring 2010 Alexandros Labrinidis, Univ. of Pittsburgh
9
Education Standards Metrics
CS 1655 / Spring 2010 Alexandros Labrinidis, Univ. of Pittsburgh
10
Phishing
E.g. activate your chase account
Data breach
Choicepoint ABN-AMRO
Attack/Hacking Denial of Service Attack
CS 1655 / Spring 2010 Alexandros Labrinidis, Univ. of Pittsburgh
11
Definition:
Body of high-level design principles and decisions that allow a
e.g., knowing that adding a certain component will not
Security architecture
serves as framework for secure design should match a defined security need often corresponds to a set of design documents
NEXT: Principles of Security Architecture
CS 1655 / Spring 2010 Alexandros Labrinidis, Univ. of Pittsburgh
12
About our worries
What can go wrong? What are we trying to protect? Who do we think might want to compromise our security? What is the weakest point in our defense?
About our resources
Do we have a security architecture? Is it used? Do we have access to reusable code libraries? What guidelines and standards are available? What are good examples that we can use for inspiration?
CS 1655 / Spring 2010 Alexandros Labrinidis, Univ. of Pittsburgh
13
About the software
Where does it stand in the chain of trust? Who are the legitimate users? Who will have access to the software (exec/source)? Do we use usage/# users changing over time? What is the environment it will run? (the big bad Web?)
About our goals
What impact would a security compromise have? Who are we willing to irritate with security measures? Do have support of others (“higher-ups”) for our security
If users go around our security measures, how will we know/
CS 1655 / Spring 2010 Alexandros Labrinidis, Univ. of Pittsburgh
14
Must wait until you are sure you understand fully what
Contrast with house building
Before architects draw plans, they must find info about: type of house Area (e.g., protect from earthquakes) building code (& restrictions) customer’s needs …
CS 1655 / Spring 2010 Alexandros Labrinidis, Univ. of Pittsburgh
15
degree of assurance required by your application is very
size and nature of your unique risks Cost of counter-measures that you program
I.e., not make applications as secure as possible, BUT
Of course, this level should be determined objectively, and not
Ideally, there are standards, as in the financial sector Example:
CS 1655 / Spring 2010 Alexandros Labrinidis, Univ. of Pittsburgh
16
Good security requires good software design and design
Main factors for security attacks:
Lack of any design Simple human weakness Poor coding practices
Good security architecture eliminates top two factors
CS 1655 / Spring 2010 Alexandros Labrinidis, Univ. of Pittsburgh
17
Must be able to stand apart from the problem at hand. Example assumptions:
If we receive a TCP packet with the SYN flag set, it means that
1) missed malicious intent 2) assume sender identity is correct The users of this software are human beings maybe a script runs instead, executing our code several
Q: How did yahoo/hotmail/gmail/etc solved this for their user
CS 1655 / Spring 2010 Alexandros Labrinidis, Univ. of Pittsburgh
18
As opposed to “patching” things in later
Just adding encryption won’t be enough!
CS 1655 / Spring 2010 Alexandros Labrinidis, Univ. of Pittsburgh
19
Try to anticipate how an attacker might approach solving
CS 1655 / Spring 2010 Alexandros Labrinidis, Univ. of Pittsburgh
20
Do not invoke untrusted programs from within trusted
General rule: do not delegate authority to take an action,
CS 1655 / Spring 2010 Alexandros Labrinidis, Univ. of Pittsburgh
21
“Principle of least privilege”
A program must operate with just enough privilege and access to
Example:
If you only need to read a value from a file, do not open with
CS 1655 / Spring 2010 Alexandros Labrinidis, Univ. of Pittsburgh
22
Make sure that moment-to-moment decisions made by
Example:
Before adding an item to shopping cart, check that cart belongs
We should not reauthenticate the user every time We should try to verify that session has not expired, the
CS 1655 / Spring 2010 Alexandros Labrinidis, Univ. of Pittsburgh
23
CERT’s recommendation:
First identify mission-critical functionality. Then, use the 3 Rs: Resistance (the capability to deter attacks) Recognition (the capability to recognize attacks and
Recovery (the capability to provide essential services and
CS 1655 / Spring 2010 Alexandros Labrinidis, Univ. of Pittsburgh
24
It is very common for improper error handling to create a
What to do:
Architect: decide on a general plan for handling errors e.g., stop only on bizarre errors and log all others Designer: how will application detect errors, discriminate
Coder: capture triggering conditions (and follow design) Operator: check processes (to see if they have stopped),
CS 1655 / Spring 2010 Alexandros Labrinidis, Univ. of Pittsburgh
25
When trouble happens, the application won’t panic, but
Examples:
SYN Flood attack: no control over number of open internet
Crumple zones in cars VMS system (by DEC): Factor limiting processor performance = memory available
Answer for performance complaints: buy more memory VMS was crash-resistant DEC sold a lot of memory :-)
CS 1655 / Spring 2010 Alexandros Labrinidis, Univ. of Pittsburgh
26
Examples:
Traffic lights are out => blink red Corporate firewall fails => network closed Time lock on bank vault => leave vault closed Computer room with electronic lock, power fails => on/off? Software to determine if iron lung machine should shut down
CS 1655 / Spring 2010 Alexandros Labrinidis, Univ. of Pittsburgh
27
Example:
When looking at authorization, assume that user does NOT have
Of course, this depends on the application (i.e. shutting off
CS 1655 / Spring 2010 Alexandros Labrinidis, Univ. of Pittsburgh
28
To be successfully you need to:
properly define the interfaces between modules limit privileges and resources to modules that really need them
Security through obscurity does not work
Reliance on obscurity is not ok However, there is value in deception (i.e. misleading attackers) Q: What is a honeypot?
CS 1655 / Spring 2010 Alexandros Labrinidis, Univ. of Pittsburgh
29
Example:
TCP SYN flood attack Maintaining state was harmful and let to exploitation
Maintaining as little or no state information makes it
CS 1655 / Spring 2010 Alexandros Labrinidis, Univ. of Pittsburgh
30
In theory there should be no difference between theory
Be realistic
Select user interface that makes it easy to do the right
Use mental models from real world Users may work around security measures that are
e.g., how often should passwords be changed?
CS 1655 / Spring 2010 Alexandros Labrinidis, Univ. of Pittsburgh
31
No group accounts Difficult for one person to pose as another Responsibility for security must be clearly assigned
Who is responsible for installing security patches?
Very common method of attack:
exhaust system resources and crash the system
Impose limits on resource consumption
e.g., number of new processes spawn, amount of memory CS 1655 / Spring 2010 Alexandros Labrinidis, Univ. of Pittsburgh
32
Logging/audit trails
For example: track changes to data
Provide consistent level of security measures throught
Also means that security measures are reasonable
CS 1655 / Spring 2010 Alexandros Labrinidis, Univ. of Pittsburgh
33
Don’t put all your security eggs in one basket :-)
CS 1655 / Spring 2010 Alexandros Labrinidis, Univ. of Pittsburgh
34