Blackboard Developers Office Hours - Secure Coding Practices - March 13, 2013

1. Developer Office Hours
Secure Coding Practices
Scott Hurrey
Developer Relations Engineer
Blackboard Partnerships
scott.hurrey@blackboard.com
202.463.4860 x2620

2. Statements regarding our product development
initiatives, including new products and future product
upgrades, updates or enhancements represent our
current intentions, but may be modified, delayed or
abandoned without prior notice and there is no
assurance that such offering, upgrades, updates or
functionality will become available unless and until
they have been made generally available to our
customers.
Developer Office Hours 2

3. Agenda
• What is Ruggedness?
• Delivering a Rugged Building Block
• Secure Design Principles
• Secure Coding Guidelines with the Private
Security APIs
• Verification Techniques
Developer Office Hours 3

4. Reference: http://www.ruggedsoftware.org/ Developer Office Hours 4

5. The Rugged Software Manifesto
Highlighting a few concepts from the manifesto
• Recognize that your Building Block becomes
part mission-critical platform
• Recognize that your code will be used (or
manipulated) in ways you cannot anticipate
• It may be attacked by talented and persistent
adversaries
• So….refuse to be the source of a vulnerability
or weakness
Developer Office Hours 5

6. Secure Starter Building Block
Features & Methodology
Highlights Common Security Pitfalls
Shows Flaws Creating Vulnerabilities
Good Code
Good Code / Bad Code Examples
Bad Code
How to Use the Security Framework
Developer Office Hours 6

7. Secure Starter Building Block
How To Access
DANGER! This is experimental code containing purposefully
designed-in vulnerabilities for teaching and learning purposes
Google Code site - bb-secure-
starter
Shortcut: http://goo.gl/3YqDq
(points to…trust me…)
http://code.google.com/p/bb-
secure-starter/
Download the B2 .war file
Install ONLY on an isolated, non-
production instance
Developer Office Hours 7

8. Secure Starter Building Block
Release 1.0.0 – Three Tutorials
Note: These are NOT vulnerabilities in Blackboard Learn Core, BUT an
insecure Building Block would expose your Blackboard Learn
instance to such issues
Three Common Security Pitfalls:
• Handling User Input
• Verifying Authenticity of Requests
• Restricting Access to Pages
Developer Office Hours 8

9. Secure Starter Building Block
Where Did It Install To?
Developer Office Hours 9

10. Secure Starter Building Block
Available Tutorials
Developer Office Hours 10

11. Definitions
Risk = Vulnerability x Threat x
Asset
Term Definition
Secure Coding Practices Input Validation, Escaping, Access Control, etc.
Vulnerability Software weakness that allows an attack to be successful
Threat Source and means of a particular type of attack
Asset Information or system of value
Risk Potential for loss, damage, or destruction of an asset as a
result of a threat exploiting a vulnerability.
Ways to Reduce Risk (severity of a potential issue):
• Reduce the Vulnerability through a Secure Coding Practice
• Reduce the Threat, perhaps through a Security Design Principle
• Reduce the Asset, perhaps through evaluating what information is
collected/modified/displayed
Developer Office Hours 11

12. Legend
Secure Design Principles
1. Defense in Depth 6. Cryptology
2. Secure Defaults 7. Fail Secure
3. Least Privilege 8. Robustness &Re-use
4. Compartmentalization 9. Expected Ability &Presence
5. Security by Obscurity is a
10. Error Handling
Myth
Developer Office Hours 12

13. Legend
Secure Coding Practices
1. Input Validation 5. File Handling
2. Escaping 6. Authenticity Validation
3. Safe HTML (Sanitation) 7. Error Handling & Exceptions
4. Arbitrary Redirects 8. Access Control
Developer Office Hours 13

14. Reflecting User Input
Bad Code
<bbNG:step title="Results" instructions="">
<c:if test="${exists == '1'}">
<h3>User ${username} located</h3>
<bbNG:dataElement label="Given Name" labelFor="givenName">
${givenName}
</bbNG:dataElement>
<bbNG:dataElement label="Email" labelFor="email">
${email}
</bbNG:dataElement>
</c:if>
</bbNG:step>
Developer Office Hours 14

15. Reflecting User Input
Good Code
<bbNG:step title="Results" instructions="">
<c:if test="${exists == '1'}">
<h3>User ${bbNG:HtmlEscape(username)} located</h3>
<bbNG:dataElement label="Given Name" labelFor="givenName">
${givenName}
</bbNG:dataElement>
<bbNG:dataElement label="Email" labelFor="email">
${email}
</bbNG:dataElement>
</c:if>
</bbNG:step>
Developer Office Hours 15

16. Restricting Access to Pages
Bad Code
Action Class
No call to check entitlements
public ActionForward saveMissingAuthorizationCheck(ActionMapping
mapping, ActionForm actionForm, HttpServletRequest request,
HttpServletResponse response) {
// immediately perform privileged actions….
}
JSP
No call to restrict access to the page (entitlement attribute)
<bbNG:genericPage ctxId="ctx">
Developer Office Hours 16

17. Restricting Access to Pages
Good Code
Action Class
Call to check entitlements in action class
public ActionForward saveMissingAuthorizationCheck(ActionMapping
mapping, ActionForm actionForm, HttpServletRequest request,
HttpServletResponse response) {
SecurityUtil.checkEntitlement
(StarterUtil.SYSTEM_ADMIN_ENTITLEMENT);
// now perform privileged actions….
}
JSP
Call to restrict access to the page (entitlement attribute)
<bbNG:genericPage ctxId="ctx" entitlement="system.admin.VIEW">
Developer Office Hours 17

18. Verifying Request Authenticity
Bad Code
Action Class
Extended LegacySecureDispatchAction
public class AuthenticityInsecureAction extends
LegacySecureDispatchAction {
// No explicit call to
// checkXSRFSecurity(actionForm, request);
JSP
Nonce not required to be passed in (isSecure, nonceId)
<bbNG:form id="exampleCourseUserForm" action="${submitUrl}“
method="POST">
Developer Office Hours 18

19. Verifying Request Authenticity
Good Code – Pre-9.1 SP10
Action Class
Keep LegacySecureDispatchAction
public class AuthenticitySecureAction extends
LegacySecureDispatchAction {
// Make explicit call to
checkXSRFSecurity(actionForm, request);
JSP
Require nonce to be passed in (isSecure=true, nonceId=package
name to ActionForm)
<bbNG:form id="exampleCourseUserForm" action="${submitUrl}“
method="POST" isSecure="true"
nonceId="blackboard.plugin.starter.struts.AuthenticityForm" >
Developer Office Hours 19

20. Verifying Request Authenticity
Good Code – Post-9.1 SP10
Action Class
Switch to SecureDispatchAction, checks nonce by default
public class AuthenticitySecureAction extends SecureDispatchAction
{
// No longer need to explicitly call nonce check
//checkXSRFSecurity(actionForm, request);
JSP
Leave as-is, nonce not required to be passed in (isSecure,
nonceId)
<bbNG:form id="exampleCourseUserForm" action="${submitUrl}“
method="POST">
Developer Office Hours 20

21. Design and Code Securely
Let’s look at a small subset of Secure
Design Principles and Secure Coding
Practices
Security Design Principles Secure Coding Practices
1. Defense in Depth 1. Input Validation
2. Compartmentalization 2. Escaping
3. Security != Obscurity 3. HTML Sanitization
4. Fail Secure
5. Least Privilege
Developer Office Hours 21

22. Defense-In-Depth
Example: TSA
“Each one of these layers
alone is capable of stopping a
terrorist attack. In
combination their security
value is multiplied, creating a
much stronger, formidable
system. A terrorist who has to
overcome multiple security
layers in order to carry out an
attack is more likely to be pre-
empted, deterred, or to fail
during the attempt.” 1
1 http://www.tsa.gov/what_we_do/layers/index.shtm
Developer Office Hours 22

23. Defense-In-Depth
Example: Blackboard Learn
 Layering security defenses in
an application can reduce the
chance of a successful attack
• Existing and upcoming
countermeasures for
Blackboard Learn
• Prevents single point of failure
• Increases robustness and future
use
Developer Office Hours 23

24. Defense-In-Depth
Your Building Block
 Follow All Secure Design Principles
 Follow All Secure Coding Guidelines
• Failure to follow these suggestions can increase the
risk of system and data compromise
• Your Building Block can affect various layers of System
Architecture beyond Blackboard Learn and circumvent
existing Security Controls
Developer Office Hours 24

25. Secure Default Settings
 Deploy B2 with minimum permissions necessary
• If a permission is not required, do not include it in your
Building Block
• For example, do not include blanket filesystem access
permissions unless absolutely necessary.
Developer Office Hours 25

26. Fail Securely
 Transaction initialization, shutdown and aborts should
always keep the application in a secure state
Example: Access Control Check
If CheckAccessDenied()
Display Error Message ()
DenyAccess()
Else
Perform Privileged Action ()
Endif
Developer Office Hours 26

27. Handling User Input
When to use Input Validation, Escaping and Safe HTML
Required Action Input Validation Escaping Safe HTML
Rendered as text Yes Yes No
Input to be added Yes Yes, but be careful No
to JavaScipt
Input to be added Yes Yes No
as a parameter to a
URL
Rendered as HTML No No Yes
Developer Office Hours 27

28. Input Validation
DO:
• Validate Input
– Applicable to ALL parameters, URLs and
HTTP Header content
– Perform at a “trust boundary” – e.g. at every
tier
– Remember DB is the last line of defense
– Use a recommended Validation Strategy
• Reject Violations
Developer Office Hours 28

29. Input Validation
Validation Strategies
Validation Strategy
(Best to Worst) Definition Often Used For
Exact match Finite list of known values, such Enumerated types or
as enumerated types or structured data
structured data
Accept known good No known list of finite values, UUIDS, pk ids,
but specific patterns strings or numbers
Sanitize with whitelist Remove/encode/replace Freeform text areas
characters not on approved list
(similar to Safe HTML)
Reject/encode known Blacklist rejection/HTML Freeform text areas
bad escaping of known malicious
chars. “Arms race”
No validation No validation N/A
Developer Office Hours 29

30. Output Encoding and Escaping
DO:
• Escape ALL untrusted data in proper
context
– Applicable to ALL input, such as URL Parameters, form fields,
headers or cookies
– Often missed when output to HTML tags and attributes, taglibs,
CSS, JavaScript data values and URIs
Context Trusted Users Untrusted Users
Non-VTBE, like Query Escape Escape
Strings
VTBE Unrestricted HTML Safe HTML
Developer Office Hours 30

31. Output Encoding and Escaping
DO NOT:
• Restrict escaping to roles unless related to
VTBE
– NO! EscapeUntrusted(), escapeThenFilter()
DO:
• Escape server-side using approved methods
Context Java JSP
HTML XSSUtil.escape(evil) ${bbNG:HtmlEscape(evil)}
JavaScript JsResource.encode(evil) ${bbFn:jsEncode(evil)}
URL EncodeUtility.urlEncode(evil) ${bbFn:urlEncode(evil)}
UrlUtil.addParameterToUrl(url,key,evil,
true) Developer Office Hours 31

32. Output Encoding and Escaping
Example
Missing escaping, remember XSSUtil.filter is not relevant
Action Class
request.setAttribute(“username”,
request.getParameter(“username”));
JSP
<h3>User ${username} located</h3>
Action Class
request.setAttribute(“username”,
XSSUtil.escape(request.getParameter(“username”)));
JSP
<h3>User ${bbNG:HtmlEscape(username)} located</h3>
Developer Office Hours 32

33. Output Encoding and Escaping
More Examples
// Escape for HTML Tags
<b>${bbNG:HtmlEscape(evil)}</b>
// Escape for HTML Attributes
<input type="text" name="foo" value="${bbNG:HtmlEscape(evil)}">
// Escape for JavaScript
<script type='text/javascript'>
function foo()
{
return confirm("${bbFn:jsEncode(evil)}")
}
</script>
// Escape for URLs
url = UrlUtil.addParameterToUrl( url, “bar", evil, true );
url = "/webapps/foo?bar="+EncodeUtility.urlEncode(evil);
<c:set var=“fooURL" value="/webapps/foo/bar.jsp?foo=${bbFn:urlEncode(evil)}"/>
Developer Office Hours 33

34. Safe HTML
DO:
• Use when rendering input to be executed
as HTML
– e.g. VTBE-related fields
DO NOT:
• Use directly from untrusted input
• Use as a replacement for appropriate input
validation or output escaping
Developer Office Hours 34

35. Safe HTML
Blacklisting
• List of URL prefixes for which the global XSS
filtering should NOT be performed.
• Add entries here to work around issues that
arise in Building Blocks or other areas that
are sensitive to the changing of request
parameter values.
• Configuration file located at
/usr/local/blackboard/content/vi/bb_bb60/plug
ins/bb-xss-filter/webapp/WEB-
INF/classes/blackboard/xss/request/bb-xss-
global-filter-exceptions.txt
Developer Office Hours 35

36. Safe HTML
Whitelisting
• This filter controls allowable HTML tags in the
Content Editor (VTBE).
• You can modify the default policy through the
UI
• Policy can be downloaded from System
Admin->Safe HTML Filters->Safe HTML Filter
for Content Editor, edited and the uploaded
via the same screen
• This only affects untrusted users, like
students
Developer Office Hours 36

37. Questions, Comments, Concerns
• Feel free to ask.
• Email me at scott.hurrey@blackboard.com
• Report Learn vulnerabilities to
LearnSecurity@blackboard.com
• Report vulnerabilities in Partner Building
Blocks to BbPartnerTeam@blackboard.com
Developer Office Hours 37