Secure programming techniques and approaches I Defence in depth PA193 – Secure coding Petr Švenda Zdeněk Říha Faculty of Informatics, Masaryk University, Brno, CZ Defence in depth • Code fails. We have to take it as a fact. All code has a nonzero likelihood of containing one or more vulnerabilities. – We have seen buffer overflow examples • You need to change your outlook from "my code is very good quality" to "though my code is the best it can be with today's knowledge, it likely still has security defects.“ – Michael Howard, Attack Surface (MSDN) Defence in depth: Definition (Wikipedia) • Non-IT: “Defence in depth (also known as deep or elastic defence) is a military strategy; it seeks to delay rather than prevent the advance of an attacker, buying time and causing additional casualties by yielding space.” • IT: “Defence in depth is an information assurance concept in which multiple layers of security controls (defence) are placed throughout an IT system. Its intent is to provide redundancy in the event a security control fails or a vulnerability is exploited that can cover aspects of personnel, procedural, technical and physical for the duration of the system's life cycle.” Defence in depth • It is an approach/concept/strategy • You have to apply it in your concrete project • This lecture will give you some hints • You have to select appropriate measures • You have to think as an attacker Basic concepts • Simplicity – Less things can go wrong – Fewer possible inconsistencies – Code is easier to understand • Restriction – Minimize access (rights) – Inhibit communication Basic concepts in more details • Simplicity – keep it simple (stupid) - KISS • Compartmentalization – Principle of least privilege – Minimize needed trust • Defence in depth – Use more than one security mechanism – Secure the weakest link – Fail securely • Work in team – Do not reinvent wheel – Code review Compartmentalization • Divide system into modules – Each module serves a specific purpose – Different modules will have different access rights – The access rights are related to activities • Example: 1. Access to files 2. Read user or network input 3. Execute privileged instructions (under root UID) • Real example: – Apache vs. suEXEC suEXEC - example • User “Alice” has a website including some CGI scripts in her own public_html folder, which can be accessed by http://server/~alice. • Bob now views Alice's webpage, which requires Apache to run one of these CGI scripts. • Instead of running all scripts as “wwwrun”, the scripts in /home/alice/public_html will be wrapped using suEXEC and run with Alice's user ID resulting in higher security and eliminating the need to make the scripts readable and executable for all users or everyone in the "wwwrun" group. Least Privilege • A subject should be given only those privileges necessary to complete its task – Function, not identity, controls – Rights added as needed and discarded after use (!) • The original formulation from Jerome Saltzer – “Every program and every privileged user of the system should operate using the least amount of privilege necessary to complete the job.” • Dynamic assignments of privileges was later discussed by Roger Needham. Least Privilege - example • On UNIX-based systems binding a program to a port number <1024 requires root privilege. – Let’s ignore modern capabilities at this moment • Many internet servers listening on well known ports (like webserver on port 80, mailserver on port 25 etc.) need to be run with root priviledge. • As soon as the port is bound the process should relinquish the root privilege as it is typically not needed anymore. • Many programs keep running with the root privileges. – After a successful attack against the process the attacker receives the power of root – “Sendmail” was well known for problems of this kind – Visual Studio required Admin privileges for long time Minimize needed trust • Minimize trust relationships • Clients, servers should not trust each other – all can get hacked – can be manipulated by users • Trusted code should not call untrusted code • Do not trust the input (!) – Separate lecture on input validation will follow • Do not trust the communication channel – Use encryption, data authentication etc. – Separate lecture on secure channel will follow Example: Web security • Web server + web client • Simple HTML form (FORM, INPUT, TEXT, MAXLENGTH, …) • Validity of fields checked by Javascript Example: Web security (2) Example: Web security (3) • The server cannot trust that the input received from the web browser will be correct with respect to the limitations specified – E.g. MAXLENGTH attribute of the INPUT fields – E.g. values will be check by the Javascript functions • It is easy to avoid these checks – Disable Javascript – Send the “filled” form directly – Tools (e.g. python request module) Fail-Safe Defaults • Default action is to deny access • Blacklist & Whitelist • Example: firewall – Default action is to drop packets – The administrator configures the firewall to allow only the packet types deemed acceptable though. • Example: input filtering – E.g. HTML tags in blog posts Example - Blacklisting of HTML • E.g. blocking the tags – ‘applet’, ‘body’, ‘bgsound’, ‘base’, ‘basefont’, ‘embed’, ‘frame’, ‘frameset’, ‘head’, ‘html’, ‘id’, ‘iframe’, ‘ilayer’, ‘layer’, ‘link’, ‘meta’, ‘name’, ‘object’, ‘script’, ‘style’, ‘title’, ‘xml’ • A new version of HTML arrives (e.g. HTML5) – New tags (like