SWE 681 ISA 681 Secure Software Design

Control the character encoding of output • Don’t let browser/user guess the character encoding – tell them (and make sure it’s right) – If browser has to guess, attacker may fool system into sending material that leads to wrong guess • Can include in HTML – • HTTP “charset” (HTTP/1. 1 is practically universally implemented, so okay to use now) 8

Metacharacters: Same issue • Escape any characters you send back that might be interpreted as metacharacters • Common problems in HTML/XML: < > & " ' • Challenge: Must ensure browser interprets them the same way – Encoding! – Again, whitelist 9

java. net. URLEncoder. encode (String s, String enc) • Translates a string into application/x-www-formurlencoded format using a specific encoding scheme (e. g. , UTF-8) • Rules (per Java spec): – Remain same: A-Z, a-z, 0 -9, ". ", "-", "*", and "_" – Space converted to “+” – All other characters are unsafe: • Converted into encoding scheme (UTF-8 recommended) • Each byte is represented by "%xy", where xy is 2 -digit hex representation • E. G. , encode("The string ü@foo-bar" , "UTF-8") produces "The+string+%C 3%BC%40 foo-bar“ – In UTF-8, ü is encoded as two bytes C 3 (hex) and BC (hex), while @ is encoded as one byte 40 (hex) 10

Escaping text in Web application frameworks • Some web application frameworks encode strings for HTML by default when outputting – Safer defaults are generally a good thing (less likely to make a mistake) • Know when escaping does & doesn’t happen – Otherwise you may escape more than once – Otherwise you might accidentally disable or circumvent escaping – Goal: Escape what you need to escape ONCE 11

Ruby on Rails • “Safe. Buffer” is String subclass for HTML text that’s safe to output – Normal String considered unsafe; user data in String by default – String. html_safe() returns Safe. Buffer version of data without escaping it (beware – do not use on untrusted user data!) – If Safe. Buffer concatenates (unsafe) String (e. g. , “<<“ or “+”), String is HTML escaped & then concatenated to produce combined Safe. Buffer – If Safe. Buffer concatenates Safe. Buffer, no additional escaping – Tag helpers concatenate application-provided tags (in Safe. Buffers) with user-provided data (auto-escaped if unsafe, per previous rule) • HTML typically generated by ERB template – Rails renders text into a Safe. Buffer; constant template data (part of application) considered safe & thus is in a Safe. Buffer – <%= ruby code to output %> is concatenated, thus results have HTML escaping applied to it if its results are unsafe (e. g. , normal string) – <%= raw … %> and <%== … %> are html_safe, not escaped (optimized) This applies to Ruby on Rails version 3 or later. Source: Koch, Henning. Everything you know about html_safe is wrong. http: //makandracards. com/makandra/2579 -everything-you-know-about-html_safe-is-wrong 12

Ruby on Rails Example ERB Template

<%= ' ' %> <%= ' '. html_safe %>

'. html_safe << '

< br />

Focus on Web applications: HTTP, HTTPS, HTML • HTTP: Protocol for requesting/sending information • HTTPS: HTTP over SSL/TLS (encrypted) • HTML: Common data format 14

HTTP • HTTP - Hyper. Text Transfer Protocol – Simple request/response protocol – Web client sends requests, web server responds – Runs on top of TCP/IP protocols • Basic protocol: – Client (e. g. , user’s web browser) sends HTTP request to HTTP server port (typically port 80) – HTTP server receives request & performs some action per request & privileges – HTTP server sends back request file (if ok) and status/error message 15

Standard HTTP request methods (per spec) • • OPTIONS: Get info on comm options GET: Retrieve information HEAD: Like GET, but just get meta-information POST: Post (form) data PUT: Store (replacement) data DELETE: Delete the resource TRACE: Show client what recipient recieves CONNECT: Reserved for future use Typically have message headers, field-name: [value] 16

HTTP Safe Methods (per HTTP specification) • GET and HEAD methods SHOULD NOT have the significance of taking any action other than retrieval – Don’t buy/sell anything, change status, etc. • User agents can represent other methods (e. g. , POST, PUT and DELETE) differently, denote “possibly unsafe” – E. g. , GET = Click on link, POST = “Submit” button – Important hint to user – helps prevent fooling user • Protocol can’t enforce, but if GET or HEAD used, “user did not request the side-effects, so therefore cannot be held accountable for them” 17

HTTP/1. 1 vs. HTTP/2 • HTTP/1. 1 is a simple text-based protocol – every line ends with CRLF (officially) – blank line ends the request • HTTP/2 is newer optimized version of HTTP – binary, not textual (faster to process & more compact) – fully multiplexed, instead of ordered and blocking • can therefore use one connection for parallelism – uses header compression to reduce overhead – designed so HTTP/1 & HTTP/2 can be translated back & forth with no loss of information • Both in wide use – HTTP/1. 1 easier to illustrate 18

Trivial HTTP/1. 1 GET request (from client to server) GET /index. html HTTP/1. 1 host: www. dwheeler. com accept-Language: en Connection: keep-alive referer: https: //www. dwheeler. com/misc. html Blank line to end the request You can send this manually using: telnet www. dwheeler. com 80 19

HTTP/1. 1 Responses • First line is “Status line” – Protocol version, 3 -digit numeric status code, & associated textual phrase – 2 xx: Success - The action was successfully received, understood, and accepted. 200=OK – 4 xx: Client Error - The request contains bad syntax or cannot be fulfilled. 404=not found, 401=unauthorized • Followed by rest of response 20

Trivial HTTP/1. 1 GET reply HTTP/1. 1 200 OK Date: Mon, 01 Oct 2012 21: 47 GMT Server: Last-Modified: Sun, 02 Sep 2012 18: 49: 14 GMT ETag: "67622 cb-9 d 4 f-7 b 3 f 5 e 80" Accept-Ranges: bytes Content-Length: 40271 Content-Type: text/html Blank line precedes reply data … 21

HTTP/1. 1 Response Splitting • HTTP/1. 1 replies (like the previous one) can include many fields • Be very careful about data sent back in fields – Especially newline & return! Attacker can create new fields/responses if can insert these – Any control characters & “: ” concerning – Whitelist, not blacklist – limit to alphanum if can – Best to limit input also (if you can) 22

Trivial HTTP/1. 1 POST Request POST /myform. html HTTP/1. 1 host: www. example. com cookie: my. Id=dwheeler referer: http: //www. example. com/index. html content-Type: application/-x-www-formurlencoded content-Length: 325 connection: keep-alive Blank line to end the header, encoded data follows 23

GET: Parameters sent as part of query string • “GET” can send information, via query string parameters – Often sent to other sites by HTTP referer header – Often stored in browser history – Often written to log files • POST sends parameters separately (body) • Use POST when: – – Doing some action that shouldn’t be auto-repeated Information is sensitive When authentication required In these cases forbid GET, don’t allow as alternative 24

HTTP Cookies: Basics • Server may reply with fields to set cookies: Set-Cookie: name=value Set-Cookie: name 2=value 2; Expires=Wed, 09 -Jun-2021 10: 18: 14 GMT • From then on, browser includes cookie values as part of requests to that domain: Cookie: name=value; name 2=value 2 • If no expiration time set, cookie expires when browser exits • If expiration time set, browser is supposed to store cookie persistently (user may erase) 25

Cookie attributes • Beyond name/value pair, cookie attributes: – cookie domain: Server domain when cookie will be sent (default: this domain, limits on alternates) – path: Path when cookie will be sent (default: this path) – expiration time or maximum age (seconds) – secure flag: Only transmit on encrypted channel – Http. Only flag: Only HTTP/HTTPS (not javascript) • Browsers will not send cookie attributes back to the server (just name/value pair) 26

Session Management • HTTP is stateless – By itself, a server doesn’t know of any relationship between “this” request (or user) & previous requests – Perfect for “please send me this static file” – Inadequate for interactive applications, shopping carts, etc. • For many applications, need to identify & manage sessions – Typically by passing a “session identifier” – User logs in, gets session id, all logged-in requests have that id – Typically exchanged in a cookie (secure, Http. Only) • Good session identifiers are not guessable • Session management, properly implemented, can prevent session hijacking and cross-site request forgery (CSRF) attacks 27

Session Management: Reuse Code • Best to use existing application container/ library for HTTP session management – Set up session ids, etc. • But check that it’s secure (may need to configure): – Session identifier should have at least 128 bits of random data (else too easily guessed) – Must use cryptographically secure pseudo-random number generator (PRNG) to generate identifier – not “add one” or roll-your-own – Encrypt session ids over untrusted channels • If you don’t, many can see session id, enables session forging 28

Always create new session when user authenticates • Even if user has an existing session, always create a new session when user authenticates – Ignore old session • Failing to do so permits “session fixation” attack – Attacker creates a new session, tricks user into using that session to authenticate against – Server sees user has a session ID & reuses it – Attacker may now be able to use session ID (that they created) to gain control with victim’s privileges 29

Session fixation attack 1. Mallory logs in & gets session_id = 111 4. Mallory re-accesses with session_id, which now has Alice’s permissions Mallory (Malicious user) 4. Server sees session_id & just reuses it, & reassociates that session_id to Alice Web Server 2. “Click here to see dancing pigs” http: //. . . ? session_ id=111 3. Alice clicks, browser goes to site & auto-provides session_id=111, username, and password Alice’s Web browser • In session fixation attack, attacker exploits server that fails to reassign session ids on login 30

Sessions: Limit Time (Idle time & session time) • Set maximum session idle time and maximum session time to reduce risk & damage – If user doesn’t log out, only short exposure time – Fewer valid session ids for attacker to guess – Even if attacker gets session id, limits time it’s valid • E. g. , an application container that implements Java Servlet: configure web. xml to set session idle timeout: 60 31

Session time: Limit maximum time • May have to implement session timeouts yourself • Java servlets: Chess book describes how to use do. Filter() to do this – Store current time for session first time request is made for that session – If session still in use after maximum lifetime, invalidate session • Be sure to provide a “logout” function for users – So users can make the time even shorter! 32

Sessions: Ensure that logging off disables cookie • Users expect that after “log off” they must “log in” to reconnect – To ensure this, log off must disable server-side session cookies to prevent its reuse – Otherwise, the cookie could continue session – Session cookies can be captured, e. g. , by malware, XSS (to be discussed), or by stealing your phone • Many systems don’t disable cookies on log off – Failures include: Office 365, Yahoo mail, Wordpress – Correctly disable: Gmail, Tweetdeck, Facebook – As of 2013 -07 -13 More info: http: //samsclass. info/123/proj 10/cookie-reuse. htm 33

Cross-Site Scripting (XSS) / Cross-Site Malicious Content • Clients (e. g. , web browsers) typically presume that server intended to send data it sent – Some secure programs (e. g. , web apps) accept data & pass that data on to a user’s application (the victim) – If the secure program doesn't protect the victim, the victim's application (e. g. , their web browser) may then process that data in a way harmful to the victim – Server isn’t subverted directly… but used as a passthrough to victim • Not called “CSS” (= Cascading Style Sheets) 34

XSS – Persistent Store Example 1. Mallory sends malicious data (e. g. , HTML comment with malicious script in it) Mallory (Malicious user) Web Server 2. Data stored & later retrieved Database 3. Alice requests info (e. g. , view comments), & receives malicious code (that may be auto-run) Alice’s Web browser • In persistent-store XSS, attacker sends data to server that is stored by server for later use • When victim requests, server includes malicious data 35

XSS –Reflection Example Web Server Mallory (Malicious user) 1. Mallory sends malicious data to Alice (e. g. , in a hypertext link/form) 3. Alice receives malicious data 2. Alice “reflected back” to sends on her… and trusts it to server Alice’s Web browser • In reflected XSS, attacker sends data to victim so victim will send it on to server – Often a special hypertext link or web form pointed to trusted server • Server then reflects data back; victim browser sees data “from” the server & trusts it 36

XSS- DOM-based • Client is tricked into sending itself attack • See: • https: //www. owasp. org/index. php/Types_of_ Cross-Site_Scripting 37

Countering XSS • Output escaping – – – Untrusted user data should be escaped before sending to user This is normally the best countermeasure: completely counters & is flexible Problem: Have to do it everywhere (easy to miss one) Many frameworks have automatic mechanisms to do this (use them!) Avoid copying data back to user – then you can’t do it wrongly (if URL bad, don’t send it back – legitimate user can see it already) • Input filtering for metacharacters – – Metacharacters include <, &, >, ", ' Forbid/remove/quote on input Often can’t do this, so often ineffective Use libraries for HTML input (e. g. , to allow … without allowing embedded Javascript) • Set Http. Only on cookies sent – Web browser scripts can’t access these cookie values – Imperfect defense, but can make some attacks harder 38

Newer XSS countermeasure: Content Security Policy (CSP) • Content Security Policy (CSP) is W 3 C Candidate Recommendation • Defines “Content-Security-Policy” HTTP header – If used, creates whitelist of sources of trusted content for this webpage – Compliant browsers only execute/render items (Javascript) from those sources • Chrome 16+, Safari 6+, and Firefox 4+. IE 10 has very limited support – Twitter and Facebook have deployed this • Typically must modify website design to fully use it – E. g. , move Javascript into separate files, otherwise receiving browser can’t distinguish whitelisted & malicious Javascript • Only works when users use compliant browsers • Expect CSP to grow additional capabilities • More info: – http: //www. html 5 rocks. com/en/tutorials/security/content-security-policy/ – http: //www. w 3. org/TR/CSP/ – https: //blog. twitter. com/2011/improving-browser-security-csp 39

Content Security Policy (CSP) helps, but is no panacea • CSP is a useful defensive measure, but can sometimes be worked around – so do not depend on it as your sole countermeasure • E. G. , evil URL:

Cross-Site Request Forgery (CSRF/XSRF) • Cross-site request forgery (CSRF/XSRF) essentially opposite of XSS – XSS exploits user’s trust in a server – CSRF/XSRF exploits server’s trust in a client • In CSRF/XSRF: – Attacker tricks user into sending data to server – Server believes that user consciously & intentionally chose that action • XSS fools clients; XSRF fools servers 41

Cross-Site Request Forgery (CSRF/XSRF) Example Web Server Mallory (Malicious user) 1. Mallory sends malicious data to Alice (e. g. , in a hypertext link/form) 2. Alice sends on to server; server acts on command “sent” by Alice’s Web browser • In CSRF/XSRF, like reflected XSS, attacker sends data to victim so victim will send it on to server – Attacker’s approach is in many ways like reflected XSS • Attacker’s purpose is for server to act on the command – Target is server not client – difference from XSS 42

Countering CSRF/XSRF • Require re-authentication (login) in critical operation • Require secret user-specific CSRF token in all forms/side-effect URLS – Attacker doesn’t know its value, so can’t insert matching token – Usual solution today, many web frameworks build this in • Use “Same. Site” cookie attribute (Lax or Strict) – not all browsers support – Asserts cookie must only be sent with requests initiated from same domain – Good long-term backwards-compatible solution – use it in addition • Check HTTP Referer or Origin header – Must treat “No Referer” as unauthorized (attacker can suppress Referer) – Some client vulnerabilities may subvert this; avoid as sole approach • Use CSRF countermeasures in login - prevent login forgery • Helpful partial countermeasures (make harder to attack): – Logoff after X minutes inactivity – Don’t allow GET (link) to have side-effects - only POST (button) • XSS vulnerabilities allow bypass of CSRF countermeasures More about Same. Site cookie attribute: https: //www. sjoerdlangkemper. nl/2016/04/14/preventing-csrf-with-samesite-cookie-attribute/ And https: //caniuse. com/#feat=same-site-cookie-attribute 43

Web applications – hardening headers to make attacks harder • Content Security Policy (CSP) – already noted • HTTP Strict Transport Security (HSTS) – “Only use HTTPS from now on for this site” • X-Content-Type-Options (as "nosniff") – Don’t guess MIME type (& confusion it can bring) • X-Frame-Options – Clickjacking protection, limits how frames may be used • X-XSS-Protection – Force enabling filter to detect likely (reflected) XSS by monitoring requests / responses – On by default in most browsers • Quick scan tool: https: //securityheaders. io/ See: https: //www. owasp. org/index. php/List_of_useful_HTTP_headers 44

Redirection • Web applications frequently redirect and forward users to other pages and websites • Don’t use unvalidated untrusted data to determine destination pages • Solutions (per OWASP): 1. 2. 3. 4. Simply avoid using redirects and forwards. If used, don’t involve user parameters in calculating the destination. This can usually be done. If destination parameters can’t be avoided, ensure that the supplied value is valid, and authorized for the user. It is recommended that any such destination parameters be a mapping value, rather than the actual URL or portion of the URL, and that server side code translate this mapping to the target URL Applications can use OWASP ESAPI to override the send. Redirect() method to make sure all redirect destinations are safe 45

Disable caching correctly for sensitive data • Web browsers normally cache web pages to storage – Greatly reduces future latency – Do not cache sensitive data – enables many attacks • Disable sensitive data caching using HTTP 1. 1 (1999) – Cache-Control: no-store • Common mistake = Using non-standard approach – Non-standard cache disabling mechanisms only disable caches on some browsers, & few test it – “Industry-wide Misunderstandings of HTTPS” (June 2013) found that 70% of tested financial, healthcare, insurance and utility account sites did it wrong (“Only IE 6 exists”) • In general, try to use standard mechanisms for security 46

Same-origin policy • Security model of Java. Script running in a web browser • Pages may only access data in a different web page if their origin is same (URI scheme + host name + port#) • Primary exceptions of same-origin policy: – Some old operations (generally predating Java. Script), e. g. , img src, submitting POST forms, and including scripts – Corner cases for pseudo-protocol schemes (e. g. file: //) – Windows (or frames) with scripts that set document. domain to the same value [can interact] – Message-passing text via post. Message() [can interact] – Web. Sockets (request sets origin, server checks if origin ok) – Cross-Origin Resource Sharing (CORS)… let’s talk about that 47

Cross-origin resource sharing (CORS) • Relaxes single-origin policy of web browsers (be careful!) • When Java. Script makes cross-origin request, “Origin: ” sent • Server examines origin & replies in HTTP header if allowed: – Access-Control-Allow-Origin: permitted origin or “*” (or null) – Access-Control-Allow-Methods: permitted methods (e. g. , GET) – Access-Control-Allow-Credentials: if true, share credentials (!) • Web browser checks if origin specifically allowed (default “no”) – Thus, both server & web browser must agree access permitted • Sometimes GET & POST are directly requested (see W 3 C spec) – In many cases web browser first makes “preflight” request to server using OPTIONS to determine permission before making actual request • Beware of Access-Control-Allow-Credentials – If “true” then credentials directly shared – only use if you totally trust other site & it’s absolutely necessary For more information, see “Exploiting CORS Misconfigurations for Bitcoins and Bounties” by Jim Kettle, Oct. 14, 2016, http: //blog. portswigger. net/2016/10/exploiting-cors-misconfigurations-for. html 48

Web applications are client/server • Web browser is a client, web server is a server • Need to not trust each other • In particular, server needs to not blindly trust what client says – Java. Script on client is great… – Server must NOT trust validation by untrusted client (including Java. Script running on client) – Yes, we’ve said this before 49

Top weakness lists, taxonomies, and style guides 50

Overview of some common top weakness lists & taxonomies • Different organizations have developed “top” weaknesses (types of flaws that can lead to a vulnerability) – Goal: Identify some specific “things to look for first” – Vulnerability lists may merge problems that can’t happen (or are less important) in a particular environment – or be specific to a different environment (web vs. embedded) – Best “top” list is the one for your project & organization – You do not need to memorize items in list or CWE numbers! – You do need to know, for a given name, what it is (if we’ve covered it) • Taxonomies try to give broader overviews/organization of weaknesses – Some organized by attack (how to attack it) – Some organized by flaws (defect which may result in security violation) • We’ll review a few “top” weakness lists & taxonomies – Help reinforce what we’ve already learned – Want you to know of some common ones (name recognition) – Haven’t covered some yet (crypto) – we will! 51

Common Vulnerabilities and Exposures (CVE) • CVE = “dictionary of publicly known information security vulnerabilities and exposures” • Vulnerability = a specific mistake in some specific software directly usable by an attacker to gain access to system/network (not just any mistake) • Exposure = a specific system configuration issue or mistake in software that allows access to information or capabilities that can be used as a stepping-stone • CVE-2013 -1380 = Specific Adobe Flash Player vulnerability • Common naming system – know if discussing same thing – Many organizations report vulnerabilities – CVE IDs let you cross-reference their reports • More info: http: //cve. mitre. org & http: //nvd. nist. gov/ 52

Common Vulnerability Scoring System (CVSS) version 2. 0 • Standard scoring system for a vulnerability (0. . 10, 10=riskiest) • Goal: Simplify prioritizing them for remediation • Base metric group - intrinsic characteristics – – – Access Vector (AV): Local, adjacent network, network Access Complexity (AC): High, medium, low Authentication (Au): Multiple, single, none Confidentiality Impact (C): None, partial, complete Integrity Impact (I): None, partial, complete Availability Impact (A): None, partial, complete • Temporal (optional) - characteristics that change over time – Exploitability (E); Remediation Level (RL); Report Confidence (RC) • Environmental (optional) - characteristics relevant to particular environment – Collateral Damage Potential (CDP); Target Distribution (TD); Security Requirements (CR, IR, AR) “A Complete Guide to the Common Vulnerability Scoring System Version 2. 0” http: //www. first. org/cvss-guide. html “CVSS version 2 calculator” http: //nvd. nist. gov/cvss. cfm? calculator&version=2 53

Common Weakness Enumeration (CWE) • Common Weakness Enumeration (CWE) = list of software weaknesses • Weakness = Type of vulnerabilities • CWE-120 = Buffer Copy without Checking Size of Input (“Classic Buffer Overflow”) • Again, common naming system – Useful as “common name” – Does have some structuring/organization (slices, graphs, parents/children)… but that’s not its strength • More info: http: //cwe. mitre. org 54

OWASP Top 10 (2017) for web applications Security Risk Covered in class session on: A 1: Injection Calling out (SQL injection, shell injection) A 2: Broken Authentication and Session Management Authentication A 3: Sensitive Data Exposure Design (least privilege), Cryptography A 4: XML External Entities (XXE) Calling out A 5: Broken Access Control Design (least privilege), Web application A 6: Security Misconfiguration Design A 7: Cross-Site Scripting (XSS) Design, Web application A 8: Insecure Deserialization Calling out A 9: Using Components with Known Vulnerabilities Obsolete code (8), Calling out, Design A 10: Insufficient Logging & Monitoring Calliing out, Design Cross-Site Request Forgery (CSRF) contentiously dropped from 2013 version. Rationale: many frameworks offer secure-by-default protections, web browsers now support Same. Site cookie attribute. 55 Source: “OWASP Top 10 2007 -2017: The Fall of CSRF” by Jack Mannino, 2017 -11 -30, https: //nvisium. com/resources/blog/2017/11/30/owasp-top-10 -2007 -2017 -the-fall-of-csrf. html

CWE/SANS Top 25 Most Dangerous Software Errors (2011) Rank ID Name [1] CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') [2] CWE-78 [3] CWE-120 Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') [4] CWE-79 Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') [5] CWE-306 Missing Authentication for Critical Function [6] CWE-862 Missing Authorization [7] CWE-798 Use of Hard-coded Credentials [8] CWE-311 Missing Encryption of Sensitive Data [9] CWE-434 Unrestricted Upload of File with Dangerous Type Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') [10] CWE-807 Reliance on Untrusted Inputs in a Security Decision 56

2011 CWE/SANS Top 25 Most Dangerous Software Errors Rank ID Name [11] CWE-250 Execution with Unnecessary Privileges [12] CWE-352 Cross-Site Request Forgery (CSRF) [13] CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') [14] CWE-494 Download of Code Without Integrity Check [15] CWE-863 Incorrect Authorization [16] CWE-829 Inclusion of Functionality from Untrusted Control Sphere [17] CWE-732 Incorrect Permission Assignment for Critical Resource [18] CWE-676 Use of Potentially Dangerous Function [19] CWE-327 Use of a Broken or Risky Cryptographic Algorithm [20] CWE-131 Incorrect Calculation of Buffer Size 57

2011 CWE/SANS Top 25 Most Dangerous Software Errors Rank ID Name [21] CWE-307 Improper Restriction of Excessive Authentication Attempts [22] CWE-601 URL Redirection to Untrusted Site ('Open Redirect') [23] CWE-134 Uncontrolled Format String [24] CWE-190 Integer Overflow or Wraparound [25] CWE-759 Use of a One-Way Hash without a Salt 58

Name NIST National Vulnerability Database (NVD): CWE subset CWE-ID Description Authentication Issues CWE-287 Failure to properly authenticate users. Credentials Management CWE-255 Failure to properly create, store, transmit, or protect passwords and other credentials. Permissions, Privileges, and Access Control CWE-264 Failure to enforce permissions or other access restrictions for resources, or a privilege management problem. CWE-119 Buffer overflows and other buffer boundary errors in which a program attempts to put more data in a buffer than the buffer can hold, or when a program attempts to put data in a memory area outside of the boundaries of the buffer. Cross-Site Request Forgery (CSRF) CWE-352 Failure to verify that the sender of a web request actually intended to do so. CSRF attacks can be launched by sending a formatted request to a victim, then tricking the victim into loading the request (often automatically), which makes it appear that the request came from the victim. CSRF is often associated with XSS, but it is a distinct issue. Cross-Site Scripting (XSS) CWE-79 Failure of a site to validate, filter, or encode user input before returning it to another user’s web client. Buffer Errors 59

Name NIST National Vulnerability Database (NVD): CWE subset CWE-ID Description CWE-310 An insecure algorithm or the inappropriate use of one; an incorrect implementation of an algorithm that reduces security; the lack of encryption (plaintext); also, weak key or certificate management, key disclosure, random number generator problems. CWE-22 When user-supplied input can contain “. . ” or similar characters that are passed through to file access APIs, causing access to files outside of an intended subdirectory. Code Injection CWE-94 Causing a system to read an attacker-controlled file and execute arbitrary code within that file. Includes PHP remote file inclusion, uploading of files with executable extensions, insertion of code into executable files, and others. Format String Vulnerability CWE-134 The use of attacker-controlled input as the format string parameter in certain functions. Configuration CWE-16 A general configuration problem that is not associated with passwords or permissions. Information Leak / Disclosure CWE-200 Exposure of system information, sensitive or private information, fingerprinting, etc. Cryptographic Issues Path Traversal 60

Name NIST National Vulnerability Database (NVD): CWE subset CWE-ID Description Input Validation CWE-20 Failure to ensure that input contains well-formed, valid data that conforms to the application’s specifications. Note: this overlaps other categories like XSS, Numeric Errors, and SQL Injection. Numeric Errors CWE-189 Integer overflow, signedness, truncation, underflow, and other errors that can occur when handling numbers. OS Command Injections CWE-78 Allowing user-controlled input to be injected into command lines that are created to invoke other programs, using system() or similar functions. Race Conditions CWE-362 The state of a resource can change between the time the resource is checked to when it is accessed. CWE-399 The software allows attackers to consume excess resources, such as memory exhaustion from memory leaks, CPU consumption from infinite loops, disk space consumption, etc. CWE-89 When user input can be embedded into SQL statements without proper filtering or quoting, leading to modification of query logic or execution of SQL commands. Resource Management Errors SQL Injection 61

Name NIST National Vulnerability Database (NVD): CWE subset CWE-ID Description Link Following CWE-59 Failure to protect against the use of symbolic or hard links that can point to files that are not intended to be accessed by the application. Other NVD is only using a subset of CWE for mapping instead of the No Mapping entire CWE, and the weakness type is not covered by that subset. Not in CWE No Mapping The weakness type is not covered in the version of CWE that was used for mapping. Insufficient Information No Mapping There is insufficient information about the issue to classify it; details are unknown or unspecified. Design Error A vulnerability is characterized as a “Design error” if there No Mapping exists no errors in the implementation or configuration of a system, but the initial design causes a vulnerability to exist. Source: http: //nvd. nist. gov/cwe. cfm 62

“A Software Flaw Taxonomy: Aiming Tools At Security” Source: “A Software Flaw Taxonomy: Aiming Tools At Security” Sam Weber Paul A. Karger Amit Paradkar http: //cwe. mitre. org/documents/sources/ ASoftware. Flaw. Taxonomy-Aiming. Toolsat. Security %5 BWeber, Karger, Paradkar%5 D. pdf 63

Weakness Classes (NSA Center for Assured Software) Weakness class Example CWEs Authentication and Access Control CWE-620: Unverified Password Change Buffer Handling [not in Java] CWE-121: Stack-based Buffer Overflow Code Quality CWE-561: Dead Code, CWE-676 Use of potentially dangerous function Control Flow Management CWE-833: Deadlock Encryption and Randomness CWE-328: Reversible One-Way Hash Error Handling CWE-252: Unchecked Return Value File Handling CWE-23: Relative Path Traversal Information Leaks CWE-534: Information Exposure Through Debug Log Files Initialization and Shutdown CWE-415: Double Free Injection CWE-134: Uncontrolled Format String Malicious Logic CWE-506: Embedded Malicious Code Number Handling CWE-369: Divide by Zero Pointer and Reference Handling CWE-476: NULL Pointer Dereference Source: http: //samate. nist. gov/ docs/CAS_2011_ SA_Tool_Method. pdf 64

WASC Threat Classification v 2. 0 • Attacks – Abuse of Functionality, Brute Force, Buffer Overflow, Content Spoofing, Credential/Session Prediction, Cross-Site Scripting, Cross-Site Request Forgery, Denial of Service, Fingerprinting, Format String, HTTP Response Smuggling, HTTP Response Splitting, HTTP Request Smuggling, HTTP Request Splitting, Integer Overflows, LDAP Injection, Mail Command Injection, Null Byte Injection, OS Commanding, Path Traversal, Predictable Resource Location, Remote File Inclusion (RFI), Routing Detour, Session Fixation, SOAP Array Abuse, SSI Injection, SQL Injection, URL Redirector Abuse, XPath Injection, XML Attribute Blowup, XML External Entities, XML Entity Expansion, XML Injection, XQuery Injection • Weaknesses – Application Misconfiguration, Directory Indexing, Improper Filesystem Permissions, Improper Input Handling, Improper Output Handling, Information Leakage, Insecure Indexing, Insufficient Anti-automation, Insufficient Authentication, Insufficient Authorization, Insufficient Password Recovery, Insufficient Process Validation, Insufficient Session Expiration, Insufficient Transport Layer Protection, Server Misconfiguration Source: http: //projects. webappsec. org/w/page/13246978/Threat%20 Classification 65

Seven Pernicious Kingdoms • • Input Validation and Representation API Abuse Security Features Time and State Error Handling Code Quality Encapsulation Source: Tsipenyuk, Chess, and Mc. Graw, “Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors”, Proceedings SSATTM, 2005 66

Software SOAR 2016 (Wheeler & Henninger) 1. Provide design and code* quality 2. Counter known vulnerabilities (CVEs) (incl. of obsolete subcomponents) 3. Ensure authentication and access control* a. b. 4. Counter unintentional-“like” weaknesses 5. Counter intentional-“like”/malicious logic* a. Known malware b. Not known malware 6. Provide anti-tamper (confidentiality of algorithms for CPI) and ensure transparency 7. Counter development tool inserted weaknesses 8. Provide secure delivery 9. Provide secure configuration 10. Other (e. g. , power) Initialization and Shutdown [of resources/components]* Design Error j. Least Privilege Control flow management* i. d. g. Permissions, Privileges, and Access Control Number Handling* h. c. Information Leaks* f. Credentials Management File Handling* e. b. Encryption and Randomness* d. Authentication Issues Injection* (SQL, command, etc. ) c. a. Buffer Handling* System Element Isolation k. Error Handling* and Fault isolation l. Pointer and reference handling* Source: State-of-the-Art Resources (SOAR) for Software Vulnerability Detection, Test, and Evaluation 2016 by David A. Wheeler and Amy E. Henninger, Institute for Defense Analyses (Paper P-8005), November 2016, https: //www. acq. osd. mil/se/initiatives/init_jfac. html * maps to NSA Center for Assured Software (CAS) structure 67

“Top” weaknesses & assurance cases on implementation • Assurance cases typically cover requirements, design, implementation, etc. – But how can you cover implementation? – “Never make implementation mistakes” is unworkable & impossible to demonstrate • More practical: Choose “top” weaknesses – Without better info, use OWASP’s top 10 for web applications and SANS/CWE 25 for anything else – Show countermeasures for each weakness (including coding guidance, detection schemes, etc. ) – Now you have a good argument! 68

Coding standards/guides 69

Coding standards/Style guides • Most languages & widely-used frameworks have at least 1 style guide in wide use • Most guides focus more on readability & generic quality – but some include security • Security-specific guides include: – SEI CERT coding standards https: //www. securecoding. cert. org/confluence/displa y/seccode/SEI+CERT+Coding+Standards – OWASP Secure Coding Practices https: //www. owasp. org/index. php/OWASP_Secure_C oding_Practices_-_Quick_Reference_Guide 70

Top 10 Secure Coding Practices (CERT/SEI) (1) Practice Description 1. Validate input from all untrusted data sources. Proper input validation can eliminate the vast majority of software vulnerabilities. Be suspicious of most external data sources, including command line arguments, network interfaces, environmental variables, and user controlled files [Seacord 05]. 2. Heed compiler warnings. Compile code using the highest warning level available for your compiler and eliminate warnings by modifying the code [C MSC 00 -A, C++ MSC 00 -A]. Use static and dynamic analysis tools to detect and eliminate additional security flaws. 3. Architect and design for security policies. Create a software architecture and design your software to implement and enforce security policies. For example, if your system requires different privileges at different times, consider dividing the system into distinct intercommunicating subsystems, each with an appropriate privilege set. 4. Keep it simple. Keep the design as simple and small as possible [Saltzer 74, Saltzer 75]. Complex designs increase the likelihood that errors will be made in their implementation, configuration, and use. Additionally, the effort required to achieve an appropriate level of assurance increases dramatically as security mechanisms become more complex. 5. Default deny. Base access decisions on permission rather than exclusion. This means that, by default, access is denied and the protection scheme identifies conditions under which access is permitted [Saltzer 74, Saltzer 75]. 71

Top 10 Secure Coding Practices (CERT/SEI) (2) Practice Description 6. Adhere to the principle of least privilege. Every process should execute with the least set of privileges necessary to complete the job. Any elevated permission should be held for a minimum time. This approach reduces the opportunities an attacker has to execute arbitrary code with elevated privileges [Saltzer 74, Saltzer 75]. 7. Sanitize data sent to other systems. Sanitize all data passed to complex subsystems [C STR 02 -A] such as command shells, relational databases, and commercial off-the-shelf (COTS) components. Attackers may be able to invoke unused functionality in these components through the use of SQL, command, or other injection attacks. This is not necessarily an input validation problem because the complex subsystem being invoked does not understand the context in which the call is made. Because the calling process understands the context, it is responsible for sanitizing the data before invoking the subsystem. 8. Practice defense in depth. Manage risk with multiple defensive strategies, so that if one layer of defense turns out to be inadequate, another layer of defense can prevent a security flaw from becoming an exploitable vulnerability and/or limit the consequences of a successful exploit. For example, combining secure programming techniques with secure runtime environments should reduce the likelihood that vulnerabilities remaining in the code at deployment time can be exploited in the operational environment [Seacord 05]. 9. Use effective quality assurance techniques. Good quality assurance techniques can be effective in identifying and eliminating vulnerabilities. Fuzz testing, penetration testing, and source code audits should all be incorporated as part of an effective quality assurance program. Independent security reviews can lead to more secure systems. External reviewers bring an independent perspective; for example, in identifying and correcting invalid assumptions [Seacord 05]. 10. Adopt a secure coding standard. Develop and/or apply a secure coding standard for your target development language and platform 72

DISA App. Sec Dev STIG • DISA “Application Security and Development STIG” – Used by Department of Defense (DOD) • Contract language, e. g. : – “(APP 3540. 1: CAT I) The Designer will ensure the application is not vulnerable to SQL injection. ” • http: //iase. disa. mil/stigs/a-z. html 73

SANS Securing Web Application Technologies (SWAT) Checklist (1) • Error handling & logging – Display generic error messages – No unhandled exceptions – Suppress framework generated errors – Log all authentication activities – Log all privilege changes – Log administrative activities – Log access to sensitive data – Do not log inappropriate data – Store logs securely • Data protection – Use SSL everywhere – Disable HTTP access for all SSL enabled resources – Use the strict- Transport-security header – Store user passwords using a strong, iterative, salted hash – Securely exchange encryption keys – Disable weak SSL ciphers on servers – Use valid SSL certificates from a reputable CA – Disable data caching using cache control headers and autocomplete – Limit the use and storage of sensitive data Source: https: //software-security. sans. org/resources/swat 74

SANS Securing Web Application Technologies (SWAT) Checklist (2) • Configuration and operations – Establish a rigorous change management process – Define security requirements – Conduct a design review – Perform code reviews – Perform security testing – Harden the infrastructure – Define an incident handling plan – Educate the team on security • Authentication – Don't hardcode credentials – Develop a strong password reset system – Implement a strong password policy – Implement account lockout against brute force attacks – Don't disclose too much information in error messages – Store database credentials securely – Applications and Middleware should run with minimal privileges 75

SANS Securing Web Application Technologies (SWAT) Checklist (3) • Session management – Ensure that session identifiers are sufficiently random – Regenerate session tokens – Implement an idle session timeout – Implement an absolute session timeout – Destroy sessions at any sign of tampering – Invalidate the session after logout – Place a logout button on every page – Use secure cookie attributes (i. e. httponly and secure flags) – Set the cookie domain and path correctly – Set the cookie expiration time • Input & output handling – – – – – Conduct contextual output encoding Prefer whitelists over blacklists use parameterized SQL queries Use tokens to prevent forged requests Set the encoding for your application Validate uploaded files Use the nosniff header for uploaded content Validate the source of input use the X-frame- options header use content security Policy (cs. P) or XXss- Protection headers 76

SANS Securing Web Application Technologies (SWAT) Checklist (4) • Access control – Apply access controls checks consistently – Apply the principle of least privilege – Don’t use direct object references for access control checks – Don’t use unvalidated forwards or redirects 77

Conclusions • Be careful sending output back – Escape metacharacters so they’re not misinterpreted by receiver • Web applications – – – Beware of session fixation, XSS, XSRF XSS fools clients; XSRF fools servers XSS: Escape output! Prefer systems that automatically do it XSRF: Secret token (always works), “Same. Site” cookie Use hardening headers (such as CSP) in addition • Developing secure software is not just knowing & countering common weaknesses – Good design! Prevent, detect, and recover! • Weakness lists can help remind/focus on biggest problems, taxonomies help describe – Once you know common past mistakes, you can avoid them – Can help justify implementation issues in an assurance case 78

Backup 79

HTTP Idempotent Methods (per HTTP specification) • “Idempotence” = aside from error or expiration issues, side-effects of > 1 identical requests same as 1 request • Methods GET, HEAD, PUT and DELETE idempotent – Not POST! • Methods OPTIONS and TRACE also idempotent – Because they SHOULD NOT have side effects at all • Beware: a sequence of several requests can be nonidempotent, even if all of its methods are idempotent – E. G. , a sequence is non-idempotent if its result depends on a value that is later modified in the same sequence 80

OWASP Top 10 (2010) Security Risk Covered in class session on: A 1: Injection Call out (SQL injection, shell injection) A 2: Cross-Site Scripting (XSS) Design/Web application A 3: Broken Authentication and Session Management Authentication A 4: Insecure Direct Object References Design (least privilege) A 5: Cross-Site Request Forgery (CSRF) Design/Web application A 6: Security Misconfiguration Design A 7: Insecure Cryptographic Storage Cryptography A 8: Failure to Restrict URL Access Design (least privilege)/web application A 9: Insufficient Transport Layer Protection Cryptography A 10: Unvalidated Redirects and Forwards Design/Web application 81

OWASP Top 10 (2013) Security Risk Covered in class session on: A 1: Injection Call out (SQL injection, shell injection) A 2: Broken Authentication and Session Management Authentication A 3: Cross-Site Scripting (XSS) Design, Web application A 4: Insecure Direct Object References Design (least privilege), Web application A 5: Security Misconfiguration Design A 6: Sensitive Data Exposure Design (least privilege), Cryptography A 7: Missing Function Level Access Control Design (least privilege) A 8: Cross-Site Request Forgery (CSRF) Design, Web application A 9: Using Components with Known Vulnerabilities Obsolete code (8), Call out, Design A 10: Unvalidated Redirects and Forwards Design, Web application 82

Released under CC BY-SA 3. 0 • This presentation is released under the Creative Commons Attribution. Share. Alike 3. 0 Unported (CC BY-SA 3. 0) license • You are free: – to Share — to copy, distribute and transmit the work – to Remix — to adapt the work – to make commercial use of the work • Under the following conditions: – Attribution — You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work) – Share Alike — If you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one • These conditions can be waived by permission from the copyright holder – dwheeler at dwheeler dot com • Details at: http: //creativecommons. org/licenses/by-sa/3. 0/ • Attribute me as “David A. Wheeler” 83