Java Security - Java IDEs to deal with security issues

Author

Java IDEs to deal with security issues

Aravind

2004-05-12, 7:55 pm

I am Aravind.Can someone suggest some Java and .NET IDEs that have
features which would help in dealing with different security issues
such as buffer overflow,SQL injection,cross site scripting etc...?.

Aravind

JoshuaBranch AS

2004-05-12, 8:38 pm

Aravind wrote:
> I am Aravind.Can someone suggest some Java and .NET IDEs that have
> features which would help in dealing with different security issues
> such as buffer overflow,SQL injection,cross site scripting etc...?.
>
> Aravind

Those issues are all very different, and I'm not sure an IDE is the tool
for managing them. If you are looking for prevention, then developers
understanding those issues is primary. Code review by those that
understand those issues is next. Then, there are tools that can try to
attack your site. Or, you can have someone try to attack your site from
the outside.

Regarding each issue you described:

- Buffer overflow: There are no buffer overflows in Java. The JVM
should always do bounds checking.

- SQL Injection: There are several best practices:
1. Never receive SQL snippets from the client. This includes all
request processing.
2. Only include client supplied parameters in the WHERE clause, and
always on one side of a comparison, representing a value.
4. When possible, use logic to translate minimal client-side
parameters to their full server-side representation. For example,
if there are two possible orders, then have the client supply a 1 or 2,
and then translate those into your corresponding column list used in
your ORDER BY. This way, the client never directly supplies the columns
you are plugging into the SQL.
5. Validate those client supplied parameters. If you have SALES > x
in your WHERE clause, and the client is supplying X, then validate that
X is numeric.
6. Isolate all dynamic SQL generation. This gives you a central
place to enforce the rules that ensure that SQL injection is not
possible. For example, this is where you might translate ordinal values
to actual lists of fields. You might also accept strong-typed
parameters there that will be included carefully in SQL. For the sales
example, it could accept only a number. With this isolation, your web
developers can do no harm because they will reference the safe API.
Someone that understands the security implications can extend the API as
web developer requirements are created.

- Cross-site scripting: This is a tough one, as it is all performed
client-side, and the user usually has to perform actions innocently.
Since cross-site scripting usually steals cookie information, the best
precaution is to

a> not include sensitive information in cookies. With today's
browsers, user's don't need their passwords saved in cookie format.
Absolutely do not store credit card and other sensitive data in cookies.
This should all be stored server-side.

b> do not rely entirely on cookies for security. They are useful for
maintaining session state, but you can add extra features, such as
binding a session to the user's IP address. You then have each request
filtered to verify it is coming from the same IP. When it comes from a
different IP, you invalidate the session and issue a security alert.
There might be remote cases where this is not practical, but I haven't
run into those cases yet. User IP's tend to be static during an HTTP
session. The only drawback is it doesn't protect from user A hijacking
user B behind the same proxy. But, at least you prevent 99.99% of the
world from being able to hijack your user's session.

How can an IDE help you with these issues? They are complex, and
require concerted high level effort in application design. The best
thing to do is develop an application framework that applies the
prevention principles, and standardize on it. Ensure that your
framework does not limit functionality or put an undo burden on
developers, or they might be tempted to work around it to meet a deadline.

___________
Erik Sliman
http://www.JoshuaBranch.com
mailto:sales.usenet.200504@JoshuaBranch.com

Aravind

2004-05-13, 5:32 am

JoshuaBranch AS <sales.usenet.200405@JoshuaBranch.com> wrote in message news:<KpidnelUSI7vLz_dRVn-hA@megapath.net>...
> Aravind wrote:
>
> Those issues are all very different, and I'm not sure an IDE is the tool
> for managing them. If you are looking for prevention, then developers
> understanding those issues is primary. Code review by those that
> understand those issues is next. Then, there are tools that can try to
> attack your site. Or, you can have someone try to attack your site from
> the outside.
>
> Regarding each issue you described:
>
> - Buffer overflow: There are no buffer overflows in Java. The JVM
> should always do bounds checking.
>
> - SQL Injection: There are several best practices:
> 1. Never receive SQL snippets from the client. This includes all
> request processing.
> 2. Only include client supplied parameters in the WHERE clause, and
> always on one side of a comparison, representing a value.
> 4. When possible, use logic to translate minimal client-side
> parameters to their full server-side representation. For example,
> if there are two possible orders, then have the client supply a 1 or 2,
> and then translate those into your corresponding column list used in
> your ORDER BY. This way, the client never directly supplies the columns
> you are plugging into the SQL.
> 5. Validate those client supplied parameters. If you have SALES > x
> in your WHERE clause, and the client is supplying X, then validate that
> X is numeric.
> 6. Isolate all dynamic SQL generation. This gives you a central
> place to enforce the rules that ensure that SQL injection is not
> possible. For example, this is where you might translate ordinal values
> to actual lists of fields. You might also accept strong-typed
> parameters there that will be included carefully in SQL. For the sales
> example, it could accept only a number. With this isolation, your web
> developers can do no harm because they will reference the safe API.
> Someone that understands the security implications can extend the API as
> web developer requirements are created.
>
> - Cross-site scripting: This is a tough one, as it is all performed
> client-side, and the user usually has to perform actions innocently.
> Since cross-site scripting usually steals cookie information, the best
> precaution is to
>
> a> not include sensitive information in cookies. With today's
> browsers, user's don't need their passwords saved in cookie format.
> Absolutely do not store credit card and other sensitive data in cookies.
> This should all be stored server-side.
>
> b> do not rely entirely on cookies for security. They are useful for
> maintaining session state, but you can add extra features, such as
> binding a session to the user's IP address. You then have each request
> filtered to verify it is coming from the same IP. When it comes from a
> different IP, you invalidate the session and issue a security alert.
> There might be remote cases where this is not practical, but I haven't
> run into those cases yet. User IP's tend to be static during an HTTP
> session. The only drawback is it doesn't protect from user A hijacking
> user B behind the same proxy. But, at least you prevent 99.99% of the
> world from being able to hijack your user's session.
>
> How can an IDE help you with these issues? They are complex, and
> require concerted high level effort in application design. The best
> thing to do is develop an application framework that applies the
> prevention principles, and standardize on it. Ensure that your
> framework does not limit functionality or put an undo burden on
> developers, or they might be tempted to work around it to meet a deadline.
>
> ___________
> Erik Sliman
> http://www.JoshuaBranch.com
> mailto:sales.usenet.200504@JoshuaBranch.com

Thanks for the reply.It helped me a lot.

Aravind

Sponsored Links