Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / April 2006

Tip: Looking for answers? Try searching our database.

Application/Code review for security

Thread view: 
Praveen - 21 Apr 2006 19:47 GMT
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 - 21 Apr 2006 20:29 GMT
>   Are there any tools available in the market which will helps us to
>generate a audit report which includes some of the following points:
[quoted text clipped - 8 lines]
>    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.

Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Thomas Hawtin - 22 Apr 2006 16:39 GMT
> 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
Signature

Unemployed English Java programmer
http://jroller.com/page/tackline/

Chris Uppal - 22 Apr 2006 18:29 GMT
> 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 - 22 Apr 2006 18:20 GMT
> 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
Signature

Unemployed English Java programmer
http://jroller.com/page/tackline/

Chris Uppal - 23 Apr 2006 10:35 GMT
> >     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())...

Sadly, I agree that that would likely happen.

Then it's P45 time.

   -- chris
steve - 22 Apr 2006 11:47 GMT
> Hi..All,
>
[quoted text clipped - 14 lines]
>
> P

yes there is , there's something on sorceforge , written by a university, was
loking yesterday , but forgotten name.

steve

Signature

NewsGuy.Com 30Gb $9.95 Carry Forward and On Demand Bandwidth

Praveen - 24 Apr 2006 22:10 GMT
Thanks a lot all!!

Another question. How far is Open Web Application Security Project
(OWASP) http://www.owasp.org known or followed while implementing the
security features.?
Can this be a selling point when doing a sales presentation to a client.

>> Hi..All,
>>
[quoted text clipped - 19 lines]
>
> steve
steve - 24 Apr 2006 23:44 GMT
> Thanks a lot all!!
>
[quoted text clipped - 27 lines]
>>
>> steve

O.K heres the link in sourceforge.

http://findbugs.sourceforge.net/

Signature

NewsGuy.Com 30Gb $9.95 Carry Forward and On Demand Bandwidth



Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.