[Check out the recap of Day 1 here]
My talk started off the presentation portion of day 2. "Real Time Application Defenses - The Reality of AppSensor & ESAP" went very well. There was a great turnout and lots of good questions. The slides are online here. If you have not heard of AppSensor then just consider this idea - What if your application could detect an attacker probing your site for weaknesses and then eliminate this threat before the attacker found and exploited a flaw in your application. That's what AppSensor allows you to do and I argue that this is the next step in application security.
The 2pm panel discussion on Vulnerability Lifecycle for Software Vendors was informative. The panel had an interesting distribution of representatives. It was nice to hear from Katie Moussouris (Microsoft) and Kelly FitzGerald (Symantec) and a somewhat different angle from Daniel Holden (Tipping Point). I was pleased that John Steven of Cigital was on the panel. He presented a distinctly different perspective on the issues and was able to represent a another demographic of companies when providing thoughts on the vulnerability lifecycle discussion
Jeremiah Grossman rounded out the day with his talk on Breaking Web Browsers. Jeremiah had interesting flaws to point out in all of the major browsers. I think most people would agree that Safari took a bit of a beating during his demos. The talk drew a good sized crowd and I also liked that our Mozilla crew was in the room to provide instant feedback on any questions related to Firefox.
To wrap up the conference there were several raffle prizes sponsored by the conference and also the attending vendors. You had to be present to win and there are likely 4-6 very sad people that wished they would have been there to claim their iPads. Oh yea, the capture the flag competition winner was announced. Samy won - go figure :)
Great conference, great to see everyone. You should have been there!
Next US conference is OWASP DC - Nov 8-11
-Michael Coates
Tuesday, September 14, 2010
AppSecUSA - Day 1 - You Missed A Good One
AppSecUSA took place last week in Irvine, CA. The conference was packed full of great talks, featured multiple keynotes and also had several good panel discussions. On top of the "official" conference agenda the "hallwaycon" was also fantastic. As Jim Manico aptly said it on twitter:
Here is a quick run down on some of the conference highlights:
Day 1
The first two keynotes were by Jeff Williams (OWASP Chair, CEO Aspect Security) and Chenxi Wang (Principal Analyst with Forrester Research). Both talks were good and caused the audience to question their thoughts on application security and the future of the field. Perhaps the most entertaining aspect of the two talks was that they presented countering views on what we should do moving forward. Jeff's talk focused on a security ecosystem that placed a strong emphasize on spreading security knowledge and capabilities to the developers and throughout the entire lifecycle.
Chenxi's talk advocated a more automated approach that allowed intelligent systems to build security into the application itself. She admitted this is more of a research area and not currenlty feasible, but that it was the direction to success. She countered Jeff's point on developer training and argued that placing a any responsibility of security into the hands of developers was a failed approach.
It was entertaining to see both perspectives and it allowed the audience to absorb both sides of the discussion and ultimately arrive at their own conclusions. If nothing else, it provided great material for people to debate in the hallways. From Jeremiah:
A Sampling of the Great Talks on Day 1
How I met your Girlfriend, Samy Kamkar
Solving Real-World Problems with an Enterprise Security API (ESAPI), Chris Schmidt,
State of SSL on the Internet - 2010 Survey, Results and Conclusions, Ivan Ristic,
Smart Phones with Dumb Apps: Threat Modeling for Mobile Applications, Dan Cornell,
Panel Discussion: Security Trends: Jeremiah Grossman, Robert Hansen
(and more, I couldn't make them all)
Security Browser Lunch
Mozilla, OWASP leaders and key web security players all gathered at lunch to determine how Mozilla and the OWASP community could further work together. A lot of great things are going to be coming down the pipeline as a result. I'm looking forward to seeing how the two organizations can work together for the mutual goal of creating a safer web. We also hope to get all the browsers at the table too - this was a last minute meeting, so no worries that others couldn't make it with such short notice.
Mozilla Content Security Policy
At the end of the day Brandon Sterne from Mozilla gave a quick presentation on the upcoming security enhancement to Firefox 4. Content Security Policy (CSP) will allow websites to effectively eliminate XSS issues through the use of policy files and a whitelist approach to only allowing externalized JavaScript (e.g. from .js files instead of inline script tags). An additional benefit of CSP is the report back capability that enables the browser to report script violations back to the site. This reporting can enable a web site to become aware of a potential xss attacks from the CSP reports from Firefox 4 users.
-Michael Coates
#appsecusa was the best InfoSec conference I have ever attended. Meeting all of the amazing people around the OWASP ecosystems was a gift.
Here is a quick run down on some of the conference highlights:
Day 1
The first two keynotes were by Jeff Williams (OWASP Chair, CEO Aspect Security) and Chenxi Wang (Principal Analyst with Forrester Research). Both talks were good and caused the audience to question their thoughts on application security and the future of the field. Perhaps the most entertaining aspect of the two talks was that they presented countering views on what we should do moving forward. Jeff's talk focused on a security ecosystem that placed a strong emphasize on spreading security knowledge and capabilities to the developers and throughout the entire lifecycle.
Chenxi's talk advocated a more automated approach that allowed intelligent systems to build security into the application itself. She admitted this is more of a research area and not currenlty feasible, but that it was the direction to success. She countered Jeff's point on developer training and argued that placing a any responsibility of security into the hands of developers was a failed approach.
It was entertaining to see both perspectives and it allowed the audience to absorb both sides of the discussion and ultimately arrive at their own conclusions. If nothing else, it provided great material for people to debate in the hallways. From Jeremiah:
Between the comments by @chenxiwang & @planetlevel the hallway track is going to be really fun. #AppSecUSA
A Sampling of the Great Talks on Day 1
How I met your Girlfriend, Samy Kamkar
Solving Real-World Problems with an Enterprise Security API (ESAPI), Chris Schmidt,
State of SSL on the Internet - 2010 Survey, Results and Conclusions, Ivan Ristic,
Smart Phones with Dumb Apps: Threat Modeling for Mobile Applications, Dan Cornell,
Panel Discussion: Security Trends: Jeremiah Grossman, Robert Hansen
(and more, I couldn't make them all)
Security Browser Lunch
Mozilla, OWASP leaders and key web security players all gathered at lunch to determine how Mozilla and the OWASP community could further work together. A lot of great things are going to be coming down the pipeline as a result. I'm looking forward to seeing how the two organizations can work together for the mutual goal of creating a safer web. We also hope to get all the browsers at the table too - this was a last minute meeting, so no worries that others couldn't make it with such short notice.
Mozilla Content Security Policy
At the end of the day Brandon Sterne from Mozilla gave a quick presentation on the upcoming security enhancement to Firefox 4. Content Security Policy (CSP) will allow websites to effectively eliminate XSS issues through the use of policy files and a whitelist approach to only allowing externalized JavaScript (e.g. from .js files instead of inline script tags). An additional benefit of CSP is the report back capability that enables the browser to report script violations back to the site. This reporting can enable a web site to become aware of a potential xss attacks from the CSP reports from Firefox 4 users.
-Michael Coates
Posted by
Michael Coates
Monday, September 13, 2010
Danger of JSP Includes and Parameter Passing
I just recently built a JSP application to demonstrate the capabilities of AppSensor and ESAPI. I decided to use strictly JSPs to keep the code relatively simple and easy to use as a reference for AppSensor ideas. During the development of this app I discovered an interesting (and concerning) behavior of JSP include tags.
Consider the following design where JSP includes are used to maximize code reusability. For each lesson the lessonIdentifier and lessonName are defined at the top of the lessonX.jsp file and then those values are passed to "preContent.jsp" which displays a bunch of info in the final jsp that is constructed.
However, take a look at lesson2.jsp below. Its the same as lesson1.jsp but the author forget to define the lessonName and lessonObjective variables and also did not include them as parameters for the jsp include statement.
Now we have a scenario where lesson2.jsp still includes the preContent.jsp from WEB-INF but has forgotten to pass the lessonName and lessonObjective variables. The code still works and no errors are thrown. This is a problem because we have now introduced a huge XSS issue. The preContent.jsp did not receive the parameters during the <jsp:include>; however, instead of displaying a null value or even throwing an error message, the reqeust.getParameter simply fails over and looks for a URL argument.
An attacker with knowledge of the source code could make the following malicious request
http://somesite.com/lesson2.jsp?lessonName=<script>alert('xss fun')</script>
Resulting Processing by the JSP:
1: lesson2.jsp includes WEB-INF/preContent.jsp
2. preContent.jsp was not given the lessonName parameter from the jsp:include and looks to the URL
3. preContent.jsp finds the URL argument and dangerously includes the user controlled data
It should be noted that the same attack on lesson1.jsp is not exploitable since the preContent.jsp finds the lessonName parameter from lesson1.jsp as part of step 2 in the process.
Conclusions
I'm very concerned by the overloaded behavior of parameter passing. In my opinion the call to request parameters from a jsp include should be different from the call to get parameters from GET or POST statements. With these changes the above scenario would not be vulnerable and would also result in a run time error indicating that the jsp include did not send the expected parameters. The current "fail-over" type behavior of reqeust.getParameter is not expected and can result in dangerous XSS vulnerabilities as indicated above.
I am interested in feedback from experienced JSP developers. How do you structure your code with JSP includes? Is this a plausible scenario in your opinion or have I just identified a poorly architected edge case scenario?
-Michael Coates
Consider the following design where JSP includes are used to maximize code reusability. For each lesson the lessonIdentifier and lessonName are defined at the top of the lessonX.jsp file and then those values are passed to "preContent.jsp" which displays a bunch of info in the final jsp that is constructed.
lesson1.jsppreContent.jsp is located within the WEB-INF folder and cannot be directly requested by a user. The only way the lesson name could be passed to this jsp is through the jsp:include from lesson1.jsp. So in the above scenario everything works great and there is no XSS concern.
<%@include file="header.jsp"%>
<%
String lessonIdentifier="1";
String lessonName="lesson 1 - attack detection";
String lessonObjective="Do something";
%>
<jsp:include page="WEB-INF/preContent.jsp">
<jsp:param name="lessonIdentifier" value="<%=lessonIdentifier%>"/>
<jsp:param name="lessonName" value="<%=lessonName%>"/>
<jsp:param name="lessonObjective" value="<%=lessonObjective%>"/>
</jsp:include>
More JSP/html content here.
<%@include file="footer.jsp"%>
WEB-INF/preContet.jsp
<div id="lessonTitle">
<b>Lesson:</b><br/> <%=request.getParameter(lessonName)%><br />
<b>Objective:</b><br/> <%=request.getParameter(lessonObjective)%>
</div>
However, take a look at lesson2.jsp below. Its the same as lesson1.jsp but the author forget to define the lessonName and lessonObjective variables and also did not include them as parameters for the jsp include statement.
lesson2.jsp
<%@include file="header.jsp"%>
<%
String lessonIdentifier="2";
//String lessonName="xxx";
//String lessonObjective="xxx";
%>
<jsp:include page="WEB-INF/preContent.jsp">
<jsp:param name="lessonIdentifier" value="<%=lessonIdentifier%>"/>
</jsp:include>
More JSP/html content here.
<%@include file="footer.jsp"%>
Now we have a scenario where lesson2.jsp still includes the preContent.jsp from WEB-INF but has forgotten to pass the lessonName and lessonObjective variables. The code still works and no errors are thrown. This is a problem because we have now introduced a huge XSS issue. The preContent.jsp did not receive the parameters during the <jsp:include>; however, instead of displaying a null value or even throwing an error message, the reqeust.getParameter simply fails over and looks for a URL argument.
An attacker with knowledge of the source code could make the following malicious request
http://somesite.com/lesson2.jsp?lessonName=<script>alert('xss fun')</script>
Resulting Processing by the JSP:
1: lesson2.jsp includes WEB-INF/preContent.jsp
2. preContent.jsp was not given the lessonName parameter from the jsp:include and looks to the URL
3. preContent.jsp finds the URL argument and dangerously includes the user controlled data
It should be noted that the same attack on lesson1.jsp is not exploitable since the preContent.jsp finds the lessonName parameter from lesson1.jsp as part of step 2 in the process.
Conclusions
I'm very concerned by the overloaded behavior of parameter passing. In my opinion the call to request parameters from a jsp include should be different from the call to get parameters from GET or POST statements. With these changes the above scenario would not be vulnerable and would also result in a run time error indicating that the jsp include did not send the expected parameters. The current "fail-over" type behavior of reqeust.getParameter is not expected and can result in dangerous XSS vulnerabilities as indicated above.
I am interested in feedback from experienced JSP developers. How do you structure your code with JSP includes? Is this a plausible scenario in your opinion or have I just identified a poorly architected edge case scenario?
-Michael Coates
Posted by
Michael Coates
Subscribe to:
Posts (Atom)