Re: Java Code Scanning

[Francisco Andrades <fandrades () nextj com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

As with any language it is very limited what you can detect with simple
greps. In C/C++ you have indeed some very risky functions, but several
exploits can exist without using any of this functions. So the first
recomendation is auditing the source code. Here is a list of a few
potential security vulnerabilitis _very_ common in Java applications:

*.- Check for SQL statements and make sure you use the PreparedStatement
class. This way you avoid SQL injections. You should not create queries
concatenating Strings.

*.- Check for open but unclosed Resultsets, PreparedStatements and
Connections to the DB. These can cause DOS attacks on your system (or
even let the system DOS itself).

*.- Whenever comparing String objects with String constants use the
equals() method on the constant: "text".equals(variable). This avoids
posible DOS attacks with malformed input.

*- Use StringBuffers whenever possible. Do not concatenate to a String
object within a loop (in most cases the compiler will optimize it to use
StringBuffers, but better do it yourself). Each concatenation may create
a new String object in the Stack, which will live until the Garbage
Collector chooses to free it, causing potential memory hogs.

*.- Do not use the String class to hold passwords. All sensitive data
must be stored in arrays. As the Strings are unmutable, so you will not
be able to erase the content of a String, and any sensitive information
will remain in the stack until the Garbage Collector decides it can be
collected.

*.- Use the NIO classes for every network access whenever possible.
Using separate Threads for each connection may expose your application
to possible DOS attacks.

*.- Check all your inputs, and be very careful when a user input is used
to calculate the size of a object (array or any container).

*.- The 'strictfp' keyword must be used with care, and you must be aware
of it's implications if used.

*.- Do not call synchronized methods from synchronized code (methods or
blocks). This most likely will result in race conditions and dead-locks
in multithreaded environments. If you must do so, then make sure the
synchronized method is only called from one synchronized piece of code.

There are a lot more guidelines, but as you can see not all can be
reduced to grep scripts as the C/C++ versions you mention. In any case
you can use a tool like jOptimizeit, but no tool will replace good design.

Peter Lee, Kah Chen wrote:
| Hi there and a good day to you,
|
| Cutting to the chase; if I am to do a textual scan of a piece of Java
| application code for potential malicious code embedded, what are the key
| words to scan for?
|
| For example in the case of C/C++ program; I might look for memory
| handling code i.e memcpy(), strcpy(), strdup(), memset(),  system
| execution code sys(), exec(), fork(), etc. IPC & RPC calls. Codes which
| try to access password directory that sort of thing.
|
| The idea is not to look for bad code writing, but to identify/flag code
| which may have security implications for more detailed sturdy or even
| code walkthrough.
|
| Anyone have a list of keywords to search with?
|
| Thanks!
|
| Peter


- --
Francisco Andrades Grassi
www.nextj.com
Tlf: +58-414-125-7415
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQE//upjGQPFH+shC0oRAo1MAKCvUa7xz5LUFFv+8R8PrKwxQfM2ZQCeO/ES
IqH4d4h3jZpd8/BmUO2AgXo=
=2ozr
-----END PGP SIGNATURE-----