Friday, December 19, 2008

Page-Level Access Controls in Struts 2 - Part 2

Background

Applications should ensure users are properly authenticated and have sufficient permissions to access pages before content is displayed. Page-level access controls are one security control that enforces this behavior.

Part 1 and 2 of this article describes one of many ways to implement a Struts 2 AuthenticationInterceptor and a RolesInterceptor to verify users have authenticated successfully and belong to an approved role before allowing access to pages. The key features targeted by both interceptors include a default deny policy and a centralized location for defining access control rules.

Struts 2 RolesInterceptor

In Part 2 of the page-level access controls article, a RolesInterceptor has been added to the struts.xml file. The "roleActions" parameter, passed to the interceptor, contains a list of actions allowed for each role. The "*" role indicates that any role can access the action.

Struts.xml

(Click the image above to view the XML)

Similar to the AuthenticationInterceptor, the RolesInterceptor verifies all users are allowed access to a particular page or validates that the user's "role" session variable matches one of the roles allowed for the action requested.

RolesInterceptor
(Click the image above to view the code)

In the ProcessSimpleLogin action, the "role" session variable has been added to include the name of the role that the user belongs to.

ProcessSimpleLogin

(Click the image above to view the code)

Thursday, November 20, 2008

Page-Level Access Controls in Struts 2 - Part 1

Background

Applications should ensure users are properly authenticated and have sufficient permissions to access pages before content is displayed. Page-level access controls are one security control that enforces this behavior.

Part 1 and 2 of this article describes one of many ways to implement a Struts 2 AuthenticationInterceptor and a RolesInterceptor to verify users have authenticated successfully and belong to an approved role before allowing access to pages. The key features targeted by both interceptors include a default deny policy and a centralized location for defining access control rules.

Struts 2 AuthenticationInterceptor

In the struts.xml file below, the AuthenticationInterceptor is defined and included in the defaultSecurityStackWithAuthentication. The "excludeActions" parameter provided to the interceptor lists the actions that do not require users to be authenticated. In this case, the "Login" and "ProcessSimpleLogin" actions do not require authentication, however the "Internal" page does require authentication.

Struts.xml

(Click the image above to view the XML)

When the AuthenticationInterceptor is called, the interceptor verifies the requested action is in the exclude list or the user has the "authenticated" session variable set to "True."

AuthenticationInterceptor

(Click the image above to view the code)

Finally, to allow users access to authenticated pages, the ProcessSimpleLogin action verifies the submitted credentials and then sets the "authenticated" session variable to "True."

ProcessSimpleLogin

(Click the image above to view the code)

The code repository containing updated struts 2 modules can be found below:

http://code.google.com/p/struts2securityaddons/

Additionally, you can see discussion of these modules in my earlier blog posts:

Monday, November 10, 2008

CSRF Prevention in Struts 2

Background

Cross-site request forgery, one of the OWASP Top 10 vulnerabilities for 2007, is an attack in which a malicious user causes a victim's browser to make a request without the user's consent. This attack is generally propagated by a third party site.

The example below shows how a CSRF attack might affect a web application that allows customers to request rental movies to be mailed to their house.

A customer logs into her movie rental web site and selects some movies to add to her queue. Next, instead of logging out of the application, she types in the address for her favorite news site, reads a few online comics, and does some research on used cars.

Unfortunately, before the customer began her research, an attacker had discovered a persistent cross-site scripting vulnerability on one of the used car sites. The attacker had also exploited this vulnerability to include a simple image tag containing a URL similar to the one below:

<img src="http://www.fakemovierentalsite.com/addMovieToQueueBeginning?movieId=12345" />

When this image tag loaded in the customer's browser, a request was sent to the movie rental application to add an embarrassing movie to the beginning of the customer's queue.

One strategy to address CSRF attacks is to require and validate one-time values included in requests to sensitive functionality. For more information, please view the OWASP explanation found here.

Struts 2 tokenSessionInterceptor

The tokenSessionInterceptor, provided by struts 2, allows developers to add CSRF protection quite easily. In the example below, the tokenSessionInterceptor was added to the interceptor stack. A parameter has been passed to the interceptor to ensure it will not be triggered on each request.

In the ProcessSimpleLogin action, the tokenSessionInterceptor is referenced again. In this case, a parameter is passed to the interceptor to ensure it verifies a valid token has been sent for this action only.


(Click the image above to view the XML)

In order to include the proper token within the page, the <s:token /> tag is included as shown below.

(Click the image above to view the code)

This strategy ensures the ProcessSimpleLogin action executes only if a one-time token has been associated with the user's session, the request includes this token, and the token has been used only one time.

The code repository containing updated struts 2 modules can be found below:

http://code.google.com/p/struts2securityaddons/

Additionally, you can see discussion of these modules in my earlier blog posts:

Sunday, November 2, 2008

Custom Error Pages in Struts 2

Background

When attackers target a particular application, they typically spend some time gathering information about the application's components, framework, and architecture. One way attackers may gather this type of information is through error messages.

Error messages often disclose SQL queries, code fragments, file names, or other sensitive information. An example is shown below.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3 xx.xx.xx.xx 10/18/08 17:49:20 clientid=&id= http://www.google.com/search?q=

[Microsoft][ODBC SQL Server Driver][SQL Server]Line 1: Incorrect syntax near '='.

SQL = "SELECT * FROM logins WHERE clientid ="

Data Source = "AFE2003"

The error occurred while processing an element with a general identifier of (CFQUERY), occupying document position (40:2) to (40:47) in the template file E:\inetpub\i\somesite\showinv\Application.cfm.

The disclosure of this information can be avoided using custom error pages. Applications, frameworks, or servers can be configured to redirect users to a custom error page that does not disclose stack traces, debugging information, or verbose error messages.

Struts 2 Custom Error Pages

Struts 2 includes an Exception Interceptor in its default stack. Developers can utilize this interceptor to catch errors and redirect users to a page containing a generic error message. One example is shown below.

Custom Error Page

(Click the image above to view the code)
Struts.xml


(Click the image above to see the XML)
Result



The code repository containing updated struts 2 modules can be found below:

http://code.google.com/p/struts2securityaddons/

Additionally, you can see discussion of these modules in my earlier blog posts:

Sunday, October 19, 2008

SSL/TLS in Struts 2

Background

SSL/TLS provides an encrypted communication channel that a client and server can use to exchange messages without an attacker eavesdropping or manipulating data in transit. This is an important security control to include within a web application to ensure attackers cannot steal user's authentication session cookies or observe user's credentials as they are transmitted to the server.

Web applications and their environments should ensure users can only access sensitive applications over an encrypted communication channel (https for example). Firewalls, application servers, or applications themselves can enforce this behavior.

Requiring SSL/TLS in Struts 2


One way to ensure users connect using SSL or TLS within struts is to create an interceptor to verify this connection. An example has been provided below.


SSLRequired.jsp

(Click the image to view the code)

RequireSSLInterceptor

(Click the image to view the code)

Struts.xml

Saturday, October 18, 2008

HTTP Caching Headers in Struts 2

Background

In many cases, the users' web browsing experience can be made more efficient by allowing web browsers to cache pages, images, scripts, and other content. This allows the web browser to retrieve content from the local disk rather than requesting data from the server every time. The end result is a quicker, more responsive user interface.

While this strategy is great for applications that handle public, non-sensitive information, it may not be appropriate for banking, investment, health care, or other similar applications. In general, applications that contain sensitive or confidential information should have controls that reduce the likelihood of information being disclosed to unauthorized individuals.

One way web applications can reduce the likelihood of browsers disclosing sensitive data through caching is to include the following HTTP headers within the server's response.

Cache-control: no-cache, no-store
Pragma: no-cache
Expires: -1
For more information, please see the OWASP AppSec FAQ.


Struts Interceptor Implementation

One way these headers can be included within a Struts 2 application is to create a custom interceptor. An example has been provided below.

CachingHeadersInterceptor Code

(Click the image above to view the code)

Struts.xml

(Click the image above to view the XML)

Results
Server: Apache-Coyote/1.1
Cache-Control: no-cache, no-store
Pragma: no-cache
Expires: -1
Content-Type: text/html
Content-Length: 157
Date: Sat, 18 Oct 2008 18:37:35 GMT

200 OK

The code repository containing updated struts 2 modules can be found below:

http://code.google.com/p/struts2securityaddons/

Additionally, you can see discussion of these modules in my earlier blog posts:

Thursday, September 4, 2008

JSESSIONID Regeneration in Struts 2

Background

Whenever a user crosses an authentication boundary, the user's session ID should be regenerated. This concept applies to a user logging into an application, logging out, or when a user reauthenticates due to a risk-based authentication process. The regeneration of session IDs is an important practice that helps eliminate session fixation vulnerabilities and may limit the impact of session theft vulnerabilities prior to authentication.

For more information on Session Fixation vulnerabilities and Session ID regeneration practices, please see the OWASP pages below:

http://www.owasp.org/index.php/Session_Fixation
http://www.owasp.org/index.php/Session_Management#Regeneration_of_Session_Tokens

Session ID Regeneration in Traditional Java Web Applications

In a J2EE application, the user's JSESSIONID cookie should be regenerated and the previous session should be removed or deleted from the server. Example code below shows how this might be accomplished in a traditional Java web application.
public class ExampleLoginServlet extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
if( //authentication was successful ) {
request.getSession().invalidate();
HttpSession session = request.getSession(true);
session.setAttribute("AUTHENTICATED", new Boolean(true));
response.sendRedirect("PageRequiringAuthentication.jsp");
//Additional Code Would Normally Follow
Session ID Regeneration in Struts 2 Applications

In Struts 2 applications, developers typically don't directly interact with the HttpServletRequest, HTTPServletResponse, or HttpSession objects. With consideration of these factors, the solution discussed above for a traditional Java web application may not be appropriate for Struts 2.

I did a little research and through trial an error I came up with a Struts 2 specific solution for regenerating JSESSIONIDs. This solution utilizes the SessionAware interface. Please excuse the unrealistic authentication code...
package nickcoblentzblog.actions.sessions;

import java.util.Map;
import org.apache.struts2.interceptor.SessionAware;
import com.opensymphony.xwork2.ActionContext;
import com.opensymphony.xwork2.ActionSupport;
import org.apache.struts2.dispatcher.SessionMap;

public class Login extends ActionSupport implements SessionAware  {
private String userid;
private String password;
private Map session;

public String execute() {
if(userid.equals("admin") && password.equals("admin"))  {

/* Session ID Regeneration: Try #4 */
((SessionMap)this.session).invalidate();
this.session = ActionContext.getContext().getSession();
/* End Try #4 */

session.put("AUTHENTICATED", new Boolean(true));


return SUCCESS;
}
else
return ERROR;
}
public String getUserid() {
return userid;
}
public void setUserid(String userid) {
this.userid = userid;
}
public String getPassword() {
return password;
}
public void setPassword(String password) {
this.password = password;
}

public void setSession(Map session) {
this.session = session;
}
}
To test this code, I followed the following procedure.

1. Cleared all browser cookies
2. Visited the Login JSP page
3. Used the Web Developer Toolbar to view my initial JSESSIONID
4. Logged into the application successfully
5. Used the Web Developer Toolbar to view my final JSESSIONID

The initial JSESSIONID value was:
AA4996C5E24BB8221BB27B23EA599F34

The final JSESSIONID value was:
325ED18851B93EBA542D2AE7926E7F8E

Based on these tests this solution appears to work successfully.

In case anyone is curious, here are a couple other ideas I toyed with:
/* Try # 1:
this.request.getSession().invalidate();
this.request.getSession(true);
*/

/* Try #2:
HTTPUtilities esapiHTTPUtilities = ESAPI.httpUtilities();
esapiHTTPUtilities.setCurrentHTTP(request, response);
try {
esapiHTTPUtilities.changeSessionIdentifier();
}
catch(Exception e) {
e.printStackTrace();
}
*/

/* Try #3:
((SessionMap)ActionContext.getContext().getSession()).invalidate();
*/


The code repository containing updated struts 2 modules can be found below:

http://code.google.com/p/struts2securityaddons/

Additionally, you can see discussion of these modules in my earlier blog posts:

Saturday, August 30, 2008

Ubiquity Security Concerns Part 1: An Introduction

Introduction

I recently watched a short video about a Mozilla Labs project called Ubiquity. After watching this video, I became extremely excited about using the features presented and extremely scared of how the extension could be exploited to compromise personal data. I wanted to both benefit from this awesome and fun extension and also find ways to execute arbitrary JavaScript within others' browsers (the same feeling I get whenever I use Google). It may be helpful to briefly watch this video to understand this sentiment:

http://www.vimeo.com/1561578?pg=embed&sec=1561578

After watching this video, my first thoughts were:

1. I wonder if an attacker could write a command to send arbitrary GMail messages on the users' behalf, watch every page the users visit, steal passwords, and even compromise users' computers.

and

2. How difficult would it be for an attacker to trick a user into installing the command or cause the command to be installed in an automated fashion?

The short answer to 1. is YES (details provided below)! Answering 2., specifically the automated portion, will require some research.

Ubiquity Developers' Awareness of Security Concerns

Before anyone gets too worked up about these security issues, I should make sure it is clear that this project is far from being complete, the authors are well aware that there a significant security concerns, and they are in the process of determining a method to reduce the risk of malicious commands or other exploits.

Examples of this awareness can be found in Atul's blog entries:

Trusting Functionality and Towards Inter-Community Trust

"At present, because our project is still in the prototyping stage, we’re opting for freedom of expressiveness and experimentation over security. That means that all the various verbs we write, while written in JavaScript, are always executed with Chrome privileges, meaning that they’re capable of doing whatever they want to the end-user’s computer."

"So the particular dilemma that needs to be solved here is: how can an end-user trust that a verb won’t do anything harmful to their data or privacy—be it intentional or accidental—while still providing a low barrier of entry for aspiring authors to write and distribute their own verbs?"

More specific concerns can be found in the Ubiquity Author Tutorial.

Ubiquity_0.1_Author_Tutorial#Sharing_it_with_the_World

"If the user chooses to subscribe to a command from an untrusted source, they will get a security warning message before they can install the command. (And in Ubiquity 0.1, ALL sources are considered untrusted, so don't take it personally!) Because Ubiquity commands can execute arbitrary javascript with chrome privileges, subscribing to a command from a website means allowing that site full access to do whatever it wants to your browser. We want to make sure people understand the dangers before subscribing to commands, so we made the warning page pretty scary."

"In the future, we're going to have something set up that we call a "trust network". When you try out a Ubiquity command from a website, and determine that the command is safe (or unsafe), you'll be able to leave an approval (or a warning). When your friends with Ubiquity installed visit the same site, they'll see the approval or the warning that you left. In this way, users will be able to rely on the judgement of other people they already know and trust in order to help them make decisions about whether a command is safe to install or not."

"By the way, the reason we call it "subscribing" to a command, rather than "installing" a command, is that if the javascript file changes -- if the site owner adds new commands, removes old commands, or updates existing commands -- all users subscribed to that URL will automatically get the updates. This will be very convenient for both users and developers, but it will also introduce another type of security risk: just because you decided a command was safe at one point in time doesn't mean that the command will always remain safe. For this reason, we'll need to make sure that the trust network keeps track of when commands have been modified, and notifies users of changes that may make a command unsafe."

Possible topics for Part 2 - ?

I plan on digging into these ideas in future posts, and have listed a few possibilities below. If you have a preference or other suggestions, feel free to leave a comment.

Using Ubiquity for Evil:
Basically, a discussion of Ubiquity features and how they could be used maliciously.

Subscription Exploits:
Results of research into whether commands could be installed in an automated fashion without the user's permission.

Ubiquity Trust Model:
Examination of how the trust model protects users from subscribing to malicious commands. This article may have to occur once that trust model has been determined by the project developers.

Saturday, August 9, 2008

Presentation Layer Output Encoding: Apache Commons Lang StringEscapeUtils vs. OWASP Reform

*Updated to include OWASP ESAPI Results on August 21, 2008*

In order to compare the effectiveness of the Apache Commons Lang StringEscapeUtils and the OWASP Reform library, I created a JSP page that encodes ASCII values from 0 to 255. I chose to examine the ability of each library to encode HTML and JavaScript values for the purpose of preventing cross-site scripting attacks. The results are shown at the bottom of this post.

In general, both the ESAPI and Reform libraries encode any value other than a-z, A-Z, and 0-9 (there are some exceptions). This is a great approach to ensuring client-side input cannot be interpreted as HTML or JavaScript commands when it is redisplayed in the browser.

ESAPI is under active development and boasts a variety of other security related functionality that may benefit an organization. I encourage everyone to take a look at the ESAPI OWASP project.

The rest of this post is provided as a reference.

Apache Commons Lang StringEscapeUtils Methods:
  • escapeHtml
  • escapeJava
  • escapeJavaScript
  • escapeSql
  • escapeXml
  • unescapeHtml
  • unescapeJava
  • unescapeJavaScript
  • unescapeXml

OWASP Reform Methods:
  • HtmlEncode
  • HtmlAttributeEncode
  • XmlEncode
  • XmlAttributeEncode
  • JsString
  • VbsString
OWASP ESAPI (SVN Snapshot 2008-08-21) Methods:
  • canonicalize
  • normalize
  • encodeForCSS
  • encodeForHTML
  • encodeForHTMLAttribute
  • encodeForJavaScript
  • encodeForVBScript
  • encodeForSQL
  • encodeForLDAP
  • encodeForDN
  • encodeForXPath
  • encodeForXML
  • encodeForXMLAttribute
  • encodeForURL
  • decodeFromURL
  • encodeForBase64
  • decodeFromBase64

Legend:
ASCII - The numerical ASCII value
Char - The symbol or character associated with that ASCII value
SEU HTML - org.apache.commons.lang.StringEscapeUtils.escapeHtml
Reform HTML - org.owasp.reform.Reform.HtmlEncode
ESAPI HTML - org.owasp.esapi.Encoder.encodeForHTML
SEU JS - org.apache.commons.lang.StringEscapeUtils.escapeJavaScript
Reform JS - org.owasp.reform.Reform.JsString
ESAPI JS - org.owasp.esapi.Encoder.encodeForJavaScript

ASCIICharSEU
HTML
Reform
HTML
ESAPI
HTML
SEU
JS
Reform
JS
ESAPI
JS
0

&#0;
\u0000'\x00'\0
1 &#1;
\u0001'\x01'\x01
2 &#2;
\u0002'\x02'\x02
3 &#3;
\u0003'\x03'\x03
4 &#4;
\u0004'\x04'\x04
5 &#5;
\u0005'\x05'\x05
6 &#6;
\u0006'\x06'\x06
7 &#7;
\u0007'\x07'\x07
8 &#8;
\b'\x08'\b
9

&#9;
\t'\x09'\t
10

&#10;
\n'\x0a'\n
11    &#11;
\u000B'\x0b'\v
12    &#12;
\f'\x0c'\f
13

&#13;
\r'\x0d'\r
14 &#14;
\u000E'\x0e'\x0E
15 &#15;
\u000F'\x0f'\x0F
16 &#16;
\u0010'\x10'\x10
17 &#17;
\u0011'\x11'\x11
18 &#18;
\u0012'\x12'\x12
19 &#19;
\u0013'\x13'\x13
20 &#20;
\u0014'\x14'\x14
21 &#21;
\u0015'\x15'\x15
22 &#22;
\u0016'\x16'\x16
23 &#23;
\u0017'\x17'\x17
24 &#24;
\u0018'\x18'\x18
25 &#25;
\u0019'\x19'\x19
26 &#26;
\u001A'\x1a'\x1A
27 &#27;
\u001B'\x1b'\x1B
28 &#28;
\u001C'\x1c'\x1C
29 &#29;
\u001D'\x1d'\x1D
30 &#30;
\u001E'\x1e'\x1E
31 &#31;
\u001F'\x1f'\x1F
32




' '
33!!&#33;&#33;!'\x21'\x21
34"&quot;&#34;&quot;\"'\x22'\"
35##&#35;&#35;#'\x23'\x23
36$$&#36;&#36;$'\x24'\x24
37%%&#37;&#37;%'\x25'\x25
38&&amp;&#38;&amp;&'\x26'\x26
39''&#39;&#39;\''\x27'\'
40((&#40;&#40;('\x28'\x28
41))&#41;&#41;)'\x29'\x29
42**&#42;&#42;*'\x2a'\x2A
43++&#43;&#43;+'\x2b'\x2B
44,,,,,',',
45--&#45;--'\x2d'-
46.....'.'.
47//&#47;&#47;\/'\x2f'\x2F
4800000'0'0
4911111'1'1
5022222'2'2
5133333'3'3
5244444'4'4
5355555'5'5
5466666'6'6
5577777'7'7
5688888'8'8
5799999'9'9
58::&#58;&#58;:'\x3a'\x3A
59;;&#59;&#59;;'\x3b'\x3B
60<&lt;&#60;&lt;<'\x3c'\x3C
61==&#61;&#61;='\x3d'\x3D
62>&gt;&#62;&gt;>'\x3e'\x3E
63??&#63;&#63;?'\x3f'\x3F
64@@&#64;&#64;@'\x40'\x40
65AAAAA'A'A
66BBBBB'B'B
67CCCCC'C'C
68DDDDD'D'D
69EEEEE'E'E
70FFFFF'F'F
71GGGGG'G'G
72HHHHH'H'H
73IIIII'I'I
74JJJJJ'J'J
75KKKKK'K'K
76LLLLL'L'L
77MMMMM'M'M
78NNNNN'N'N
79OOOOO'O'O
80PPPPP'P'P
81QQQQQ'Q'Q
82RRRRR'R'R
83SSSSS'S'S
84TTTTT'T'T
85UUUUU'U'U
86VVVVV'V'V
87WWWWW'W'W
88XXXXX'X'X
89YYYYY'Y'Y
90ZZZZZ'Z'Z
91[[&#91;&#91;['\x5b'\x5B
92\\&#92;&#92;\\'\x5c'\\
93]]&#93;&#93;]'\x5d'\x5D
94^^&#94;&#94;^'\x5e'\x5E
95__&#95;__'\x5f'_
96``&#96;&#96;`'\x60'\x60
97aaaaa'a'a
98bbbbb'b'b
99ccccc'c'c
100ddddd'd'd
101eeeee'e'e
102fffff'f'f
103ggggg'g'g
104hhhhh'h'h
105iiiii'i'i
106jjjjj'j'j
107kkkkk'k'k
108lllll'l'l
109mmmmm'm'm
110nnnnn'n'n
111ooooo'o'o
112ppppp'p'p
113qqqqq'q'q
114rrrrr'r'r
115sssss's's
116ttttt't't
117uuuuu'u'u
118vvvvv'v'v
119wwwww'w'w
120xxxxx'x'x
121yyyyy'y'y
122zzzzz'z'z
123{{&#123;&#123;{'\x7b'\x7B
124||&#124;&#124;|'\x7c'\x7C
125}}&#125;&#125;}'\x7d'\x7D
126~~&#126;&#126;~'\x7e'\x7E
127&#127;
'\x7f'\x7F
128&#128;&#128;
\u0080'\u0080'\x80
129&#129;&#129;
\u0081'\u0081'\x81
130&#130;&#130;
\u0082'\u0082'\x82
131ƒ&#131;&#131;
\u0083'\u0083'\x83
132&#132;&#132;
\u0084'\u0084'\x84
133&#133;&#133;
\u0085'\u0085'\x85
134&#134;&#134;
\u0086'\u0086'\x86
135&#135;&#135;
\u0087'\u0087'\x87
136ˆ&#136;&#136;
\u0088'\u0088'\x88
137&#137;&#137;
\u0089'\u0089'\x89
138Š&#138;&#138;
\u008A'\u008a'\x8A
139&#139;&#139;
\u008B'\u008b'\x8B
140Œ&#140;&#140;
\u008C'\u008c'\x8C
141&#141;&#141;
\u008D'\u008d'\x8D
142Ž&#142;&#142;
\u008E'\u008e'\x8E
143&#143;&#143;
\u008F'\u008f'\x8F
144&#144;&#144;
\u0090'\u0090'\x90
145&#145;&#145;
\u0091'\u0091'\x91
146&#146;&#146;
\u0092'\u0092'\x92
147&#147;&#147;
\u0093'\u0093'\x93
148&#148;&#148;
\u0094'\u0094'\x94
149&#149;&#149;
\u0095'\u0095'\x95
150&#150;&#150;
\u0096'\u0096'\x96
151&#151;&#151;
\u0097'\u0097'\x97
152˜&#152;&#152;
\u0098'\u0098'\x98
153&#153;&#153;
\u0099'\u0099'\x99
154š&#154;&#154;
\u009A'\u009a'\x9A
155&#155;&#155;
\u009B'\u009b'\x9B
156œ&#156;&#156;
\u009C'\u009c'\x9C
157&#157;&#157;
\u009D'\u009d'\x9D
158ž&#158;&#158;
\u009E'\u009e'\x9E
159Ÿ&#159;&#159;
\u009F'\u009f'\x9F
160 
&nbsp;&#160;&nbsp;\u00A0'\u00a0'\xA0
161¡&iexcl;&#161;&iexcl;\u00A1'\u00a1'\xA1
162¢&cent;&#162;&cent;\u00A2'\u00a2'\xA2
163£&pound;&#163;&pound;\u00A3'\u00a3'\xA3
164¤&curren;&#164;&curren;\u00A4'\u00a4'\xA4
165¥&yen;&#165;&yen;\u00A5'\u00a5'\xA5
166¦&brvbar;&#166;&brvbar;\u00A6'\u00a6'\xA6
167§&sect;&#167;&sect;\u00A7'\u00a7'\xA7
168¨&uml;&#168;&uml;\u00A8'\u00a8'\xA8
169©&copy;&#169;&copy;\u00A9'\u00a9'\xA9
170ª&ordf;&#170;&ordf;\u00AA'\u00aa'\xAA
171«&laquo;&#171;&laquo;\u00AB'\u00ab'\xAB
172¬&not;&#172;&not;\u00AC'\u00ac'\xAC
173­&shy;&#173;&shy;\u00AD'\u00ad'\xAD
174®&reg;&#174;&reg;\u00AE'\u00ae'\xAE
175¯&macr;&#175;&macr;\u00AF'\u00af'\xAF
176°&deg;&#176;&deg;\u00B0'\u00b0'\xB0
177±&plusmn;&#177;&plusmn;\u00B1'\u00b1'\xB1
178²&sup2;&#178;&sup2;\u00B2'\u00b2'\xB2
179³&sup3;&#179;&sup3;\u00B3'\u00b3'\xB3
180´&acute;&#180;&acute;\u00B4'\u00b4'\xB4
181µ&micro;&#181;&micro;\u00B5'\u00b5'\xB5
182&para;&#182;&para;\u00B6'\u00b6'\xB6
183·&middot;&#183;&middot;\u00B7'\u00b7'\xB7
184¸&cedil;&#184;&cedil;\u00B8'\u00b8'\xB8
185¹&sup1;&#185;&sup1;\u00B9'\u00b9'\xB9
186º&ordm;&#186;&ordm;\u00BA'\u00ba'\xBA
187»&raquo;&#187;&raquo;\u00BB'\u00bb'\xBB
188¼&frac14;&#188;&frac14;\u00BC'\u00bc'\xBC
189½&frac12;&#189;&frac12;\u00BD'\u00bd'\xBD
190¾&frac34;&#190;&frac34;\u00BE'\u00be'\xBE
191¿&iquest;&#191;&iquest;\u00BF'\u00bf'\xBF
192À&Agrave;&#192;&Agrave;\u00C0'\u00c0'\xC0
193Á&Aacute;&#193;&Aacute;\u00C1'\u00c1'\xC1
194Â&Acirc;&#194;&Acirc;\u00C2'\u00c2'\xC2
195Ã&Atilde;&#195;&Atilde;\u00C3'\u00c3'\xC3
196Ä&Auml;&#196;&Auml;\u00C4'\u00c4'\xC4
197Å&Aring;&#197;&Aring;\u00C5'\u00c5'\xC5
198Æ&AElig;&#198;&AElig;\u00C6'\u00c6'\xC6
199Ç&Ccedil;&#199;&Ccedil;\u00C7'\u00c7'\xC7
200È&Egrave;&#200;&Egrave;\u00C8'\u00c8'\xC8
201É&Eacute;&#201;&Eacute;\u00C9'\u00c9'\xC9
202Ê&Ecirc;&#202;&Ecirc;\u00CA'\u00ca'\xCA
203Ë&Euml;&#203;&Euml;\u00CB'\u00cb'\xCB
204Ì&Igrave;&#204;&Igrave;\u00CC'\u00cc'\xCC
205Í&Iacute;&#205;&Iacute;\u00CD'\u00cd'\xCD
206Î&Icirc;&#206;&Icirc;\u00CE'\u00ce'\xCE
207Ï&Iuml;&#207;&Iuml;\u00CF'\u00cf'\xCF
208Ð&ETH;&#208;&ETH;\u00D0'\u00d0'\xD0
209Ñ&Ntilde;&#209;&Ntilde;\u00D1'\u00d1'\xD1
210Ò&Ograve;&#210;&Ograve;\u00D2'\u00d2'\xD2
211Ó&Oacute;&#211;&Oacute;\u00D3'\u00d3'\xD3
212Ô&Ocirc;&#212;&Ocirc;\u00D4'\u00d4'\xD4
213Õ&Otilde;&#213;&Otilde;\u00D5'\u00d5'\xD5
214Ö&Ouml;&#214;&Ouml;\u00D6'\u00d6'\xD6
215×&times;&#215;&times;\u00D7'\u00d7'\xD7
216Ø&Oslash;&#216;&Oslash;\u00D8'\u00d8'\xD8
217Ù&Ugrave;&#217;&Ugrave;\u00D9'\u00d9'\xD9
218Ú&Uacute;&#218;&Uacute;\u00DA'\u00da'\xDA
219Û&Ucirc;&#219;&Ucirc;\u00DB'\u00db'\xDB
220Ü&Uuml;&#220;&Uuml;\u00DC'\u00dc'\xDC
221Ý&Yacute;&#221;&Yacute;\u00DD'\u00dd'\xDD
222Þ&THORN;&#222;&THORN;\u00DE'\u00de'\xDE
223ß&szlig;&#223;&szlig;\u00DF'\u00df'\xDF
224à&agrave;&#224;&agrave;\u00E0'\u00e0'\xE0
225á&aacute;&#225;&aacute;\u00E1'\u00e1'\xE1
226â&acirc;&#226;&acirc;\u00E2'\u00e2'\xE2
227ã&atilde;&#227;&atilde;\u00E3'\u00e3'\xE3
228ä&auml;&#228;&auml;\u00E4'\u00e4'\xE4
229å&aring;&#229;&aring;\u00E5'\u00e5'\xE5
230æ&aelig;&#230;&aelig;\u00E6'\u00e6'\xE6
231ç&ccedil;&#231;&ccedil;\u00E7'\u00e7'\xE7
232è&egrave;&#232;&egrave;\u00E8'\u00e8'\xE8
233é&eacute;&#233;&eacute;\u00E9'\u00e9'\xE9
234ê&ecirc;&#234;&ecirc;\u00EA'\u00ea'\xEA
235ë&euml;&#235;&euml;\u00EB'\u00eb'\xEB
236ì&igrave;&#236;&igrave;\u00EC'\u00ec'\xEC
237í&iacute;&#237;&iacute;\u00ED'\u00ed'\xED
238î&icirc;&#238;&icirc;\u00EE'\u00ee'\xEE
239ï&iuml;&#239;&iuml;\u00EF'\u00ef'\xEF
240ð&eth;&#240;&eth;\u00F0'\u00f0'\xF0
241ñ&ntilde;&#241;&ntilde;\u00F1'\u00f1'\xF1
242ò&ograve;&#242;&ograve;\u00F2'\u00f2'\xF2
243ó&oacute;&#243;&oacute;\u00F3'\u00f3'\xF3
244ô&ocirc;&#244;&ocirc;\u00F4'\u00f4'\xF4
245õ&otilde;&#245;&otilde;\u00F5'\u00f5'\xF5
246ö&ouml;&#246;&ouml;\u00F6'\u00f6'\xF6
247÷&divide;&#247;&divide;\u00F7'\u00f7'\xF7
248ø&oslash;&#248;&oslash;\u00F8'\u00f8'\xF8
249ù&ugrave;&#249;&ugrave;\u00F9'\u00f9'\xF9
250ú&uacute;&#250;&uacute;\u00FA'\u00fa'\xFA
251û&ucirc;&#251;&ucirc;\u00FB'\u00fb'\xFB
252ü&uuml;&#252;&uuml;\u00FC'\u00fc'\xFC
253ý&yacute;&#253;&yacute;\u00FD'\u00fd'\xFD
254þ&thorn;&#254;&thorn;\u00FE'\u00fe'\xFE
255ÿ&yuml;&#255;&yuml;\u00FF'\u00ff'\xFF

Thursday, August 7, 2008

SAML Research Road Map

Recently, I have been asked by several people about SAML as it pertains to single sign-on for web applications. At the time, I was not familiar with this standard or the technology surrounding it and decided to do some research. I discovered there were a lot of valuable resources on the web, but there was not an easy to understand road map describing the order in which to read these items.

This article is an attempt to provide that road map, so others can understand and appreciate SAML.

Note: This article pertains to SAML 2.0 and not SAML 1.x.

Introduction

From the OASIS SAML Technical Overview Document:

“The OASIS Security Assertion Markup Language (SAML) standard defines an XML-based framework for describing and exchanging security information between on-line business partners.”

While this description makes sense to those already familiar with SAML, it may be incomprehensible to everyone else. To help everyone else, I’m going to provide a simplified, high-level overview. Then, once some of the basics have been established, I will provide a resource from the OASIS site that describes the technical details of the SAML standard.

High-level Overview

The SAML standard can be broken down into several components, some of which are listed below.
  • SAML Assertions
  • SAML Protocols
  • SAML Bindings
  • SAML Profiles
SAML Profiles or Use Cases

SAML Profiles are a collection of SAML components organized into use cases suited to solve a business problem or need. Examples of major profiles or use cases defined within the SAML Standard are listed below.
  • Web Browser Single Sign-On Profile (Web Browser SSO)
  • Single Logout Profile
  • Web Services Security (WS-Security) and SAML
The goal of the Web Browser SSO profile is to provide a single sign-on experience for users to move seamlessly between web applications of disparate organizations or companies. For example, if three distinct companies providing complimentary services (such as a hotel booking, flight booking, and car rental service) wish to form a partnership, they can create a single sign-on experience for their users (and share information) without the consolidation of servers or data.

The Single Logout Profile provides a mechanism to simultaneously log a user out of all sites participating in a particular single sign-on experience.

The combination of WS-Security and SAML is actually an extension of SAML and not directly defined as a profile. However, this use case is a valuable way to use SAML as a security token for authentication and authorization of a principle interacting with a system through SOAP web services.

SAML Assertions

SAML Assertions consist of XML data that contains authentication, authorization, or additional attributes about a principal (a user, application, or other subject wishing to access a resource). SAML assertions are often provided by an identity provider or authentication service to a service provider. The service provider can understand the Assertions and trusts the identity provider due to agreements made between the organizations that own or operate the services.

An example assertion is shown below. Discussion of the structure of a SAML Assertion will be addressed by a resource provided later in this article.


SAML Protocols

SAML Protocols define mechanisms for communicating SAML Assertions between identity providers, principals, and service providers. The standard provides a detailed set of request and response strategies to suit a variety of business and technical requirements.

SAML 2.0 includes the following protocols:
  • Assertion Query and Request Protocol
  • Authentication Request Protocol
  • Artifact Resolution Protocol
  • Name Identifier Management Protocol
  • Single Logout Protocol
  • Name Identifier Mapping Protocol
An example request and response is shown below. Discussion of the SAML Protocol sequences and the structure of the request and response below will be addressed by a resource provided later in this article.

SAML Protocol Authentication Request:


SAML Protocol Authentication Response:


SAML Bindings

SAML Bindings determine how SAML messages are encapsulated within other protocols such as HTTP or SOAP. SAML 2.0 describes the following bindings:
  • SAML SOAP Binding
  • Reverse SOAP (PAOS) Binding
  • HTTP Redirect (GET) Binding
  • HTTP POST Binding
  • HTTP Artifact Binding
  • SAML URI Binding

Next Step

Now that a basic understanding of SAML has been established, I suggest reading the Security Assertion Markup Language (SAML) V2.0 Technical Overview. This document is written by OASIS and summarizes the SAML standard in a way that is easy to understand.

What About Security?

There are many security considerations that must be analyzed before the implementation of a product leveraging SAML takes place. Often authentication or authorization information is allowed to pass through untrusted users or may be intercepted by attackers. The Security and Privacy Considerations for the OASIS
Security Assertion Markup Language (SAML) V2.0 document provides a detailed discussion of these issues and appropriate mitigation techniques.

If I was asked to summarize the mitigation strategies described in this document, I would provide the following recommendations:
  • Use TLS/SSL 3.0 with strong ciphers and verifiable certificates (usually for just the server, but sometimes needed for the client as well).
  • If the application must ensure data integrity remains intact, use XML Signature to ensure it is not manipulated while in transit.
  • If confidential, sensitive, or private data passes through the client use XML Encryption to ensure it is not disclosed to unauthorized parties.

Wednesday, August 6, 2008

Threat Modeling as the Only Secure Development Activity

Purpose

This article discusses why it is important for threat modeling to be supported by a full secure development process within an organization. If threat modeling is the only secure development activity performed, it will be difficult to identify threats, mitigate risks, and leverage knowledge gained during threat modeling efforts in future projects.

This article does NOT describe how to perform threat modeling, however it does provide a brief introduction to ensure it is clear what the author means by the term "threat modeling."

Introduction to Threat Modeling

At its core, threat modeling is a secure development activity in which developers, architects, designers, security personnel, and sometimes managers consider possible attack scenarios or threats against an application. This process typically occurs during a planning or design phase of development before any code is written.

One threat modeling strategy may include the following steps:

1. Resource <- 2. Capability <- 3. Use Case <- User
1. Resource <- 2. Capability <- 4. Threats <- Attacker

  1. Identify resources within the application, such as database tables, file systems, and application servers.
  2. Determine the capabilities or actions that can be performed on each item. One example for a database table may be to read checking account transaction data.
  3. Consider the proper way in which a valid user may invoke a capability. Following with the previous example, a customer may login to Online Banking and access their checking account details.
  4. Consider the threats to a particular resource based on the associated capabilities. Threat modeling participants can base threats on defined use cases or by brainstorming in a free form manner. Example: An attacker may wish to access another user's checking account data.
  5. Assign a risk level to each threat, such as high, medium, and low.
  6. Define countermeasures based on the analysis of the risk level vs. the cost of implementing the solution
There are many ways threat modeling can be performed. For more information, please visit the OWASP Threat Modeling page.


Threat Modeling as the Only Secure Development Activity

Threat modeling is a necessary component within a secure development process. However, if threat modeling is the only security activity your organization has implemented, you may not be realizing its full value or potential.

During the threat modeling process, threats and countermeasures must be defined. Typically, it is difficult for threat modeling participants to think from an attacker's perspective without basic application security awareness training. Often, the end result will be an incomplete threat model that does not include enough of the relevant application attack scenarios or threats.

Once threats have been enumerated, participants must identify viable and effective countermeasures. The most effective countermeasures are those based on application security best practices. Often, developers are not familiar with these best practices leading to the creation of countermeasures that only partial protect resources. Security training is necessary to provide application security knowledge and these essential best practices.

Once appropriate countermeasures have been designed, implemented, and tested to ensure they are complete and effective solutions for eliminating risks, this knowledge should be captured to be reused in future projects. If this knowledge is not captured, the organization will be forced to start from scratch each and every time threat modeling is performed. This can be an unnecessary allocation of time or money.

To effectively capture and reuse this knowledge, an organization should wrap security best practices and solutions into the organization's security policies and secure coding standards. In future projects, the designer or requirements specifier can create security requirements based on this documentation. During the threat modeling process, threats can be matched up with defined security requirements allowing participants to focus on threats that have not been mitigated in past efforts.

Conclusion

Threat modeling should not be the only secure development activity used within an organization. It must be supported by a full process including security training, security policies, secure coding standards, and many more activities. The OWASP Comprehensive, Lightweight Application Security Process is one fully featured secure development process that should be considered.

OWASP CLASP Overview Presentation

The OWASP Comprehensive, Lightweight Application Security Process (CLASP) is an "Activity driven, role-based set of process components whose core contains formalized best practices for building security into your existing or new-start software development life cycles in a structured, repeatable, and measurable way"

In other words, it is one method of many (others examples are Microsoft SDL and Software Security Touchpoints) for implementing a secure development process.

A couple months ago, I created a presentation that gave a high-level overview of CLASP. I wanted to make this presentation available to the community as well as gather input from industry practitioners regarding how feasible this model is within their environment. I encourage anyone who is interested to join the OWASP CLASP mailing list or comment directly.

The presentation can be found here: OWASP CLASP Overview