Penetration Testing mailing list archives
RE: java source code audit
From: "Debasis Mohanty" <debasis.mohanty.listmails () gmail com>
Date: Thu, 4 Oct 2007 22:16:01 +0530
Because they developed a client of their own instead of using a Web
browser,
I'm discarding XSS, Parameter tamping, XST, etc...
that would be a dangerous mistake you would make. There are proxies for interception/modification of non-http/https traffic as well. One such proxy is ITR (Interactive TCP Relay). Search in google for the link. Parameter tampering would still be possible using such proxies irrespective of the client is custom developed or not.
My question is: what kind of vulnerability should I check for?
sometime back i replied to a similar query in another mailing list; you may like to read my mail below - From: Debasis Mohanty <debasis.mohanty.listmails_at_gmail.com> Date: Wed, 27 Jun 2007 23:23:05 +0530
What program(s) do you use in static code analysis? It doesn't matter if you are a hardcore grep+editor researcher or if you use complex frameworks: Tell me (and also the rest of the list) about it.
Secure code review is one of the most mis-guided field where many security folks talks only about grep'ing for threat patterns. Offcourse I do not rule out it as a starting point but there are lot more to it. I have my own approach to secure code review: A simpler and easy to go approach is - a) Build up a Taxonomy of security coding errors specific to various platforms The taxonomy of coding errors defined by Gary McGraw (cigital.com) in famous book "Software Security - Building Security In" is good starting point to base line with. There are several such taxonomies of coding errors floating around but most of them seems to be flawed in some or the other way. I found McGraw's classification for errors (i.e. security flaws) to be useful and can be made a part of both manual and automatic code review. A nice write up on various such taxonomies can be found here - http://securesoftware.blogspot.com/2005/12/threat-vulnerabilities-classifica tion.html Moving further you can refer CWE (http://cwe.mitre.org/data/dictionary.html) which presently seems to be superset of all common software weaknesses. b) Create a set of secure coding anti-patterns specific to various platforms Secure coding anti-patterns are commonly used poor solutions to common security problems. This comes handy in getting more accurate results when you run the anti-pattern cheat sheet through the code. For Example: * Use of an unbounded copy char buf[1024]; strcpy(buf, s); * Use of a bounded copy with incorrect calculations char buf[1024]; strncpy(buf, s, 1025); Both the above piece of code snippet is vulnerable. One more example is - not always a check for NULL value will take care of a NP (Null Pointer) dereference bug. i.e. there are many weak ways of preventing NP errors which doesn't warrant a *hard to break* protection. check out https://www.blackhat.com/presentations/win-usa-03/bh-win-03-schoenfeld.pdf http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-2594&y r=2007&track=5 google for secure coding antipatterns to find more references. c) Grep for anti-patterns or secure coding mistakes Use you favorite editor here and grep for all security anti-patterns. I am a great fan of SciTE which supports almost all languages. get it here http://scintilla.sourceforge.net/ Though this is an important phase during code review but definitely not an ultimate phase to find security holes. The important phase is what comes next i.e. Manual Data Flow (DF) and Control Flow (CF) analysis. d) Manual Data Flow (DF) and Control Flow (CF) analysis DF analysis - http://en.wikipedia.org/wiki/Data_flow_analysis CF analysis - http://en.wikipedia.org/wiki/Control_flow_graph Performing both DF and CF analysis manually takes lot of time but is definitely most important part of code review. It helps identifying accurate threats from security standpoint. This phase requires a master code security ninja's hand to ensure actual issues are captured. For example: Not always you see request.getparameter (" ") in java can be flagged for a potential XSS vector. In other words it is necessary to check - whether the data can be directly or indirectly be tampered by an malicious user at any given point of time to cause a successfull XSS attack - check whether the data is sanitised for malicious inputs before it is directly written to user page. - check whether the data is encoded before written back to user page similarly there are lot of such factors based on which a code reviewer will be able to decide whether the finding is actually a threat or not. Few code review optimization tricks - - know languages like python or ruby so that you can write some scripts to automate step "c" and "d". - Every time you find unique anti-patterns do update your anti-pattern cheat sheet - For easiness decompose a big application into various modules for code review. - Prioritize the security anti-patterns based on your own skills to identify them faster and accurately. For example, I am fast at finding XSS anti-patterns compared to NP exceptions. So I'll push NP anti-patterns towards the end. - If at any point of time, a particular issue is taking more time to investigate then tag it for future review and move on to next. Thats all I have for now.... hope it helps. -d -----Original Message----- From: listbounce () securityfocus com [mailto:listbounce () securityfocus com] On Behalf Of Guillermo Caminer Sent: 04 October 2007 04:52 To: pen-test () securityfocus com Subject: java source code audit Hi list! I'm doing a source code audit of a client-server application developed in Java. They're using Hibernate, so I'm discarding SQL injection vulnerabilities. Because they developed a client of their own instead of using a Web browser, I'm discarding XSS, Parameter tamping, XST, etc... Also, they don't have any 'Bad session store' vulnerabilities. Finally, because of Java, Buffer overflows are out of the picture. My question is: what kind of vulnerability should I check for? Thanks in advance! ------------------------------------------------------------------------ ------------------------------------------------------------------------ This list is sponsored by: Cenzic Need to secure your web apps NOW? Cenzic finds more, "real" vulnerabilities fast. Click to try it, buy it or download a solution FREE today! http://www.cenzic.com/downloads ------------------------------------------------------------------------
Current thread:
- java source code audit Guillermo Caminer (Oct 03)
- Re: java source code audit Robin Sheat (Oct 03)
- Re: java source code audit David M. Zendzian (Oct 04)
- Re: java source code audit Brian Toovey (Oct 03)
- Message not available
- Re: java source code audit Brian Toovey (Oct 04)
- Re: java source code audit SD List (Oct 05)
- Message not available
- Re: java source code audit Robin Sheat (Oct 03)
- Re: java source code audit AdityaK (Oct 04)
- RE: java source code audit Debasis Mohanty (Oct 04)
- <Possible follow-ups>
- Re: java source code audit nmonkee (Oct 04)
- Re: java source code audit cwright (Oct 04)