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