Re: applet security

[Steve Barnet <barnet () chem wisc edu>]

test.future () gmail com wrote:
> > Maybe it _calls_ server side code (by hitting
> > urls or other channel), but it doesn't run 
> > there.
> > Maybe they want you to put "controls" on that code?
>
>
> If that really is what they mean, what controls can be put in place to mitigate the risk? 
> I can think of input filtering and validation on server side code to defend against buffer 
> overflow. Any other measure besides this? 
>
> I don't understand what they mean by "environment attacks". Any one can share some thought on this? Thanks.

This could have a variety of meanings:

1) Environment variables on the client side can be an
   input source for an applet. People frequently overlook
   this when they write input validation code.

2) Environment variables on the client side can alter
   the execution environment - code can be interposed
   between the app and the runtime libraries or OS (for
   example, a custom library that intercepts traffic destined
   for an SSL tunnel before it's encrypted).

3) Code which alters browser state (creates cookies, uploads
   other applets, etc) may provide an intrusion vector.

I suppose that in a more general sense, it greatly expands the
possible sources of input your applications must deal with.

Looking at the document you pointed out, it appears to be a whole lot of
auditor boilerplate. Make no mistake, many of these points are codifying
lessons learned at the sharp end of the stick and merit consideration in
the security of your system. However, when I see general statements
like these which are devoid of specific context, it appears that the
auditors simply regurgitated the document to pad the report. I'll bet
if you ask them for specific instances of where this can/should apply
to your system they won't have much to say.

A point to consider in placing controls to mitigate these risks is
that ultimately what all of these points boil down to is that you
can't trust the client system. There are myriad ways to alter the
applet execution environment many of which are limited only by the
creativity and skill of the attacker. The biggest implication of
that concept is that your server side code cannot assume that the
client system will pass only valid requests or data to the backend
systems.

You also cannot assume that data passed to your applet will only be
handled by that applet. I saw an example of this recently when ordering
some tickets online. The institution would keep track of your account
info (most notably credit card number) for convenience of future
transactions. If you viewed your account details, you saw only the last
four digits of the number. Using the l33t hacking tool "View Source" in
my browser, I was able to see that they transmitted the entire number to
the browser and used an applet to return only the last four digits.

Bad code.

This translates to (at least) two ideas in writing code:

1) Backend code must verify the integrity of all requests and data it
   receives.
2) If information should not be available at the client side, don't
   send it.

Common sense, but often ignored.

Best,

---Steve


-------------------------------------------------------------------------
This List Sponsored by: Watchfire

Watchfire's AppScan is the industry's first and leading web application 
security testing suite, and the only solution to provide comprehensive 
remediation tasks at every level of the application. See for yourself. 
Download AppScan 6.0 today.

https://www.watchfire.com/securearea/appscansix.aspx?id=701300000003Ssh
--------------------------------------------------------------------------