WebApp Sec mailing list archives
Re: applet security
From: Steve Barnet <barnet () chem wisc edu>
Date: Thu, 12 Jan 2006 09:09:33 -0600
test.future () gmail com wrote:
Maybe it _calls_ server side code (by hittingurls 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: WatchfireWatchfire'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 --------------------------------------------------------------------------
Current thread:
- applet security test . future (Jan 09)
- RE: applet security Andrew Chong (Jan 09)
- Re: applet security Dean H. Saxe (Jan 09)
- RE: applet security Richard M. Smith (Jan 10)
- <Possible follow-ups>
- RE: applet security Jeff Robertson (Jan 09)
- Re: applet security test . future (Jan 11)
- Re: applet security Michael Silk (Jan 11)
- Re: Re: applet security test . future (Jan 12)
- Re: applet security Steve Barnet (Jan 12)
- RE: Re: applet security Andrew Chong (Jan 12)
- Re: Re: applet security test . future (Jan 12)
- RE: applet security Andrew Chong (Jan 09)