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 O’Reilly, 2003 First chapter is available online: http://www.securecoding.org 2 � Alexandros Labrinidis, Univ. of Pittsburgh � CS 1655 / Spring 2010 � 1
One example When: late 1996 Where: earth (internet problems affect all!) What: TCP SYN Flood attack Why: “not playing by the rules” Real-life equivalent: A calls B B hangs up A does not hang up Result: B’s phone is busy! (no longer the case :-)) 3 � Alexandros Labrinidis, Univ. of Pittsburgh � CS 1655 / Spring 2010 � Vulnerability Cycle 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 are ok, the rest are victims… 4 � Alexandros Labrinidis, Univ. of Pittsburgh � CS 1655 / Spring 2010 � 2
Attacks and defenses Architectural-design level attacks: Man-in-the-middle Race-condition Replay Sniffer Session hijacking Session killing 5 � Alexandros Labrinidis, Univ. of Pittsburgh � CS 1655 / Spring 2010 � Attacks and defenses Implementation-level attacks Buffer-overflow Back door attack Parsing error attack 6 � Alexandros Labrinidis, Univ. of Pittsburgh � CS 1655 / Spring 2010 � 3
Attacks and defenses Operations-level attacks Denial-of-service Default accounts Password cracking policies 7 � Alexandros Labrinidis, Univ. of Pittsburgh � CS 1655 / Spring 2010 � Why good people write bad code Technical Factors In other fields, the whole may be greater than the sum of its parts, in computer security the sum of the parts is often a hole! 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 8 � Alexandros Labrinidis, Univ. of Pittsburgh � CS 1655 / Spring 2010 � 4
What can be done? Education Standards Metrics 9 � Alexandros Labrinidis, Univ. of Pittsburgh � CS 1655 / Spring 2010 � Making things clear Phishing E.g. activate your chase account Data breach Choicepoint ABN-AMRO Attack/Hacking Denial of Service Attack 10 � Alexandros Labrinidis, Univ. of Pittsburgh � CS 1655 / Spring 2010 � 5
Security Architecture Definition: Body of high-level design principles and decisions that allow a programmer to say “yes” with and confidence and “No” with certainty e.g., knowing that adding a certain component will not compromise the security of your system 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 11 � Alexandros Labrinidis, Univ. of Pittsburgh � CS 1655 / Spring 2010 � Principles of Security Architecture 1. Start by asking questions 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? 12 � Alexandros Labrinidis, Univ. of Pittsburgh � CS 1655 / Spring 2010 � 6
Principles of Security Architecture 1. Start by asking questions 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 precautions? If users go around our security measures, how will we know/ handle it? 13 � Alexandros Labrinidis, Univ. of Pittsburgh � CS 1655 / Spring 2010 � Principles of Security Architecture 2. Select a destination before stepping on the gas Must wait until you are sure you understand fully what needs to be done, before starting making decisions. 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 … 14 � Alexandros Labrinidis, Univ. of Pittsburgh � CS 1655 / Spring 2010 � 7
Principles of Security Architecture 3. Decide how much security is just enough degree of assurance required by your application is very strongly related to: size and nature of your unique risks Cost of counter-measures that you program I.e., not make applications as secure as possible, BUT make applications just secure enough Of course, this level should be determined objectively, and not because you ran out of time :-) Ideally, there are standards, as in the financial sector Example: require biometric identification for all amazon.com purchases 15 � Alexandros Labrinidis, Univ. of Pittsburgh � CS 1655 / Spring 2010 � Principles of Security Architecture 4. Employ standard engineering techniques Good security requires good software design and design techniques. Main factors for security attacks: Lack of any design Simple human weakness Poor coding practices Good security architecture eliminates top two factors only 16 � Alexandros Labrinidis, Univ. of Pittsburgh � CS 1655 / Spring 2010 � 8
Principles of Security Architecture 5. Identify your assumptions 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 the sender wants to start a dialog with us 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 thousand times a second… Q : How did yahoo/hotmail/gmail/etc solved this for their user signup systems? 17 � Alexandros Labrinidis, Univ. of Pittsburgh � CS 1655 / Spring 2010 � Principles of Security Architecture 6. Engineer security in from day one As opposed to “patching” things in later Just adding encryption won’t be enough! 18 � Alexandros Labrinidis, Univ. of Pittsburgh � CS 1655 / Spring 2010 � 9
Principles of Security Architecture 7. Design with the enemy in mind Try to anticipate how an attacker might approach solving the “puzzle” of breaking your security infrastructure. 19 � Alexandros Labrinidis, Univ. of Pittsburgh � CS 1655 / Spring 2010 � Principles of Security Architecture 8. Understand and respect the chain circle of trust Do not invoke untrusted programs from within trusted ones! General rule : do not delegate authority to take an action, without delegating responsibility to check if action is appropriate. 20 � Alexandros Labrinidis, Univ. of Pittsburgh � CS 1655 / Spring 2010 � 10
Principles of Security Architecture 9. Be stingy with privileges “Principle of least privilege” A program must operate with just enough privilege and access to accomplish its objectives. Example: If you only need to read a value from a file, do not open with read/write permissions. 21 � Alexandros Labrinidis, Univ. of Pittsburgh � CS 1655 / Spring 2010 � Principles of Security Architecture 10. Test any proposed action against policy Make sure that moment-to-moment decisions made by software are in accordance with the up-to-date security settings. Example: Before adding an item to shopping cart, check that cart belongs to user. We should not reauthenticate the user every time We should try to verify that session has not expired, the connection has not been broken, no rules were added about shopping carts… 22 � Alexandros Labrinidis, Univ. of Pittsburgh � CS 1655 / Spring 2010 � 11
Recommend
More recommend
