Home > Archive > Java Security > April 2006 > Application/Code review for security
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Application/Code review for security
|
|
| Praveen 2006-04-21, 7:08 pm |
| Hi..All,
Are there any tools available in the market which will helps us to
generate a audit report which includes some of the following points:
Use of and tampering with hidden fields
SQL Injection
Cookie “poisoning”
URL parameter tampering
Variable checking within application code
Buffer overflows within application code
cryptography algorithm your application utilizes.
strength of this encryption algorithm
hashing function
Regards,
P
| |
| Roedy Green 2006-04-21, 7:08 pm |
| On Fri, 21 Apr 2006 18:47:21 GMT, Praveen <nospam@nospam.com> wrote,
quoted or indirectly quoted someone who said :
> Are there any tools available in the market which will helps us to
>generate a audit report which includes some of the following points:
>
> Use of and tampering with hidden fields
> SQL Injection
> Cookie “poisoning”
> URL parameter tampering
> Variable checking within application code
> Buffer overflows within application code
> cryptography algorithm your application utilizes.
> strength of this encryption algorithm
> hashing function
What you could do in create a list of packages that would have to be
present for various types of error to be made. Then you could at
least provide a list of source files with what needs to be checked.
You could also create some regexes that looked for certain methods and
could automate some check to decide : good, bad, irrelevant, unknown.
Since you can wrap the crucial methods so many levels deep, I can't
see how you would statically be able to check. Perhaps you could do
it by adding monitoring code on crucial methods to log important facts
as the program ran using the debug interface.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
| |
|
| On Sat, 22 Apr 2006 02:47:21 +0800, Praveen wrote
(in article <ZM92g.62585$F_3.49699@newssvr29.news.prodigy.net> ):
> Hi..All,
>
> Are there any tools available in the market which will helps us to
> generate a audit report which includes some of the following points:
>
> Use of and tampering with hidden fields
> SQL Injection
> Cookie =93poisoning=94
> URL parameter tampering
> Variable checking within application code
> Buffer overflows within application code
> cryptography algorithm your application utilizes.
> strength of this encryption algorithm
> hashing function
>
>
> Regards,
>
> P
yes there is , there's something on sorceforge , written by a university, was
loking yesterday , but forgotten name.
steve
--
NewsGuy.Com 30Gb $9.95 Carry Forward and On Demand Bandwidth
| |
| Thomas Hawtin 2006-04-22, 7:05 pm |
| Roedy Green wrote:
>
> What you could do in create a list of packages that would have to be
> present for various types of error to be made. Then you could at
> least provide a list of source files with what needs to be checked.
> You could also create some regexes that looked for certain methods and
> could automate some check to decide : good, bad, irrelevant, unknown.
Grep is great for finding bugs, but I think byte code analysis will be
better for making sure you haven't missed any bugs.
It's like the difference between finding a counter example in a
mathematical hypothesis and creating a proof without flaws.
> Since you can wrap the crucial methods so many levels deep, I can't
> see how you would statically be able to check. Perhaps you could do
> it by adding monitoring code on crucial methods to log important facts
> as the program ran using the debug interface.
Tainting seems to have some success. Mark values from external sources
as tainted, and watch for their use in sensitive methods.
A different approach that seems to be becoming more popular recently is
fuzzing. Take a load of valid data, make random corruptions and see if
it is handled incorrectly. For example, in the late nineties testing for
the Kimera JVM found 21 errors (not necessarily exploitable security
bugs) in the Sun JVM.
Tom Hawtin
--
Unemployed English Java programmer
http://jroller.com/page/tackline/
| |
| Chris Uppal 2006-04-22, 7:05 pm |
| Thomas Hawtin wrote:
> Tainting seems to have some success. Mark values from external sources
> as tainted, and watch for their use in sensitive methods.
A quick, distinctly limited, and very, very dirty approximation -- but one
which I nevertheless suspect would expose /lots/ of potential flaws -- would be
to check that the SQL String parameter to [implementations of]
java.sql.Statement.execute(), and the like, satisfies:
sql == sql.intern()
-- chris
| |
| Thomas Hawtin 2006-04-22, 7:05 pm |
| Chris Uppal wrote:
>
> A quick, distinctly limited, and very, very dirty approximation -- but one
> which I nevertheless suspect would expose /lots/ of potential flaws -- would be
> to check that the SQL String parameter to [implementations of]
> java.sql.Statement.execute(), and the like, satisfies:
>
> sql == sql.intern()
Heh. I think the downside is that if you reported that sort of flaw to
the author, then the author would be the sort of person to fix it with
statement.execute(sql.intern())...
Tom Hawtin
--
Unemployed English Java programmer
http://jroller.com/page/tackline/
| |
| Chris Uppal 2006-04-25, 7:17 pm |
| Thomas Hawtin wrote:
>
> Heh. I think the downside is that if you reported that sort of flaw to
> the author, then the author would be the sort of person to fix it with
> statement.execute(sql.intern())...
Sadly, I agree that that would likely happen.
Then it's P45 time.
-- chris
|
|
|
|
|