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.

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

ASCII	Char	SEU HTML	Reform HTML	ESAPI HTML	SEU JS	Reform JS	ESAPI JS
0			�		\u0000	'\x00'	\0
1					\u0001	'\x01'	\x01
2					\u0002	'\x02'	\x02
3					\u0003	'\x03'	\x03
4					\u0004	'\x04'	\x04
5					\u0005	'\x05'	\x05
6					\u0006	'\x06'	\x06
7					\u0007	'\x07'	\x07
8					\b	'\x08'	\b
9						\t	'\x09'	\t
10			
		\n	'\x0a'	\n
11					\u000B	'\x0b'	\v
12					\f	'\x0c'	\f
13			
		\r	'\x0d'	\r
14					\u000E	'\x0e'	\x0E
15					\u000F	'\x0f'	\x0F
16					\u0010	'\x10'	\x10
17					\u0011	'\x11'	\x11
18					\u0012	'\x12'	\x12
19					\u0013	'\x13'	\x13
20					\u0014	'\x14'	\x14
21					\u0015	'\x15'	\x15
22					\u0016	'\x16'	\x16
23					\u0017	'\x17'	\x17
24					\u0018	'\x18'	\x18
25					\u0019	'\x19'	\x19
26					\u001A	'\x1a'	\x1A
27					\u001B	'\x1b'	\x1B
28					\u001C	'\x1c'	\x1C
29					\u001D	'\x1d'	\x1D
30					\u001E	'\x1e'	\x1E
31					\u001F	'\x1f'	\x1F
32						' '
33	!	!	!	!	!	'\x21'	\x21
34	"	"	"	"	\"	'\x22'	\"
35	#	#	#	#	#	'\x23'	\x23
36	$	$	$	$	$	'\x24'	\x24
37	%	%	%	%	%	'\x25'	\x25
38	&	&	&	&	&	'\x26'	\x26
39	'	'	'	'	\'	'\x27'	\'
40	(	(	(	(	(	'\x28'	\x28
41	)	)	)	)	)	'\x29'	\x29
42	*	*	*	*	*	'\x2a'	\x2A
43	+	+	+	+	+	'\x2b'	\x2B
44	,	,	,	,	,	','	,
45	-	-	-	-	-	'\x2d'	-
46	.	.	.	.	.	'.'	.
47	/	/	/	/	\/	'\x2f'	\x2F
48	0	0	0	0	0	'0'	0
49	1	1	1	1	1	'1'	1
50	2	2	2	2	2	'2'	2
51	3	3	3	3	3	'3'	3
52	4	4	4	4	4	'4'	4
53	5	5	5	5	5	'5'	5
54	6	6	6	6	6	'6'	6
55	7	7	7	7	7	'7'	7
56	8	8	8	8	8	'8'	8
57	9	9	9	9	9	'9'	9
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
65	A	A	A	A	A	'A'	A
66	B	B	B	B	B	'B'	B
67	C	C	C	C	C	'C'	C
68	D	D	D	D	D	'D'	D
69	E	E	E	E	E	'E'	E
70	F	F	F	F	F	'F'	F
71	G	G	G	G	G	'G'	G
72	H	H	H	H	H	'H'	H
73	I	I	I	I	I	'I'	I
74	J	J	J	J	J	'J'	J
75	K	K	K	K	K	'K'	K
76	L	L	L	L	L	'L'	L
77	M	M	M	M	M	'M'	M
78	N	N	N	N	N	'N'	N
79	O	O	O	O	O	'O'	O
80	P	P	P	P	P	'P'	P
81	Q	Q	Q	Q	Q	'Q'	Q
82	R	R	R	R	R	'R'	R
83	S	S	S	S	S	'S'	S
84	T	T	T	T	T	'T'	T
85	U	U	U	U	U	'U'	U
86	V	V	V	V	V	'V'	V
87	W	W	W	W	W	'W'	W
88	X	X	X	X	X	'X'	X
89	Y	Y	Y	Y	Y	'Y'	Y
90	Z	Z	Z	Z	Z	'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
97	a	a	a	a	a	'a'	a
98	b	b	b	b	b	'b'	b
99	c	c	c	c	c	'c'	c
100	d	d	d	d	d	'd'	d
101	e	e	e	e	e	'e'	e
102	f	f	f	f	f	'f'	f
103	g	g	g	g	g	'g'	g
104	h	h	h	h	h	'h'	h
105	i	i	i	i	i	'i'	i
106	j	j	j	j	j	'j'	j
107	k	k	k	k	k	'k'	k
108	l	l	l	l	l	'l'	l
109	m	m	m	m	m	'm'	m
110	n	n	n	n	n	'n'	n
111	o	o	o	o	o	'o'	o
112	p	p	p	p	p	'p'	p
113	q	q	q	q	q	'q'	q
114	r	r	r	r	r	'r'	r
115	s	s	s	s	s	's'	s
116	t	t	t	t	t	't'	t
117	u	u	u	u	u	'u'	u
118	v	v	v	v	v	'v'	v
119	w	w	w	w	w	'w'	w
120	x	x	x	x	x	'x'	x
121	y	y	y	y	y	'y'	y
122	z	z	z	z	z	'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

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.
  

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