Re: [WEB SECURITY] web security

[Andrew van der Stock <vanderaj@xxxxxxxxxx>]

My $2.50 (= my posts are rarely short, and therefore $0.02 will not  
suffice)

I feel that tampering of client side data and validation is not  
really the level you should be aiming at for a post graduate thesis.

This issue is partially to mostly solved in some web frameworks, and  
in others, adequate controls are provided with careful server-side  
validation. Other approaches include the "Dejection" paper presented  
at Blackhat last year by some really cool UoIowa folks (Hansen and  
Patterson, http://www.cs.uiowa.edu/~mlpatter/), which uses  
mathematical models and grammar to provide proof that data should be  
safe. I'd hate for you to research for a year or two and only move  
this semi-mature area along just a fraction.

Instead, choose something really meaty and unsolved. Even if you  
don't manage to solve it, you will almost certainly move the field  
along quite significantly.

My personal choice? Business-significant secure automated code review  
processes / tools is an essentially unsolved problem that could  
really do with some high-level thought.

Current static analysis tools, such as Parasoft's excellent  
JTest, .NET's prefast and fxcop, and Compuwares' similar offerings,  
and many others, do a fine job of pointing out highly technical, but  
usually low business risk items, such as code which fails to include  
the "final" keyword on constant strings. I've never seen money lost  
or reputations damaged through failing to heed these types of warnings.

In my experience, these tools hamper the code review process by  
consuming usually limited time available, which could be used to find  
more important things. I tend to encourage developers to use these  
tools as a sort of security lint, but find myself with my old friend  
grep as about the only tool in my arsenal. I'd like more tools to  
assist with whole of system analysis, and this time, I'd like the  
tools to be useful. And that's where the research comes in.

I regularly review larger apps, and I'm always frustrated at the  
amount of time it takes me to:

a) Create an accurate map of the code and find the trust boundaries.  
In the rare cases it is complete, the documentation is rarely right.  
Even if it is right as far as the components documented, the solution  
architects are usually completely unaware of the ... shortcuts ...  
that the devs had to make to get the thing delivered on time.

Yesterday whilst I was poking around for speakers at OWASP AppSec  
Europe, I was reminded of Bill Cheswick, who spoke at SAGE-AU a few  
years back. He created these beautiful "peacock maps" of the  
Internet. I believe they're still out there somewhere. I was thinking  
that mapping code like this might make sense of huge incomprehensible  
code bases. It's important to know where one trust level and the next  
interact, and color mapping software like this could be useful.

b) Automatically (or help reduce the effort of) identify and map  
business relevant process flows within the app in a larger system,  
which may cross many language and protocol boundaries. This is  
probably impossible, even though this is where the highest level of  
business risk is imparted to an application.

c) Determine if the threat is real or not. I know if I see lack of  
data validation there is some risk, but in other cases, there might  
be extenuating circumstances, such as lower layer systems which  
provide adequate protection. I see this as a hard problem. When I'm  
not allowed to tinker with a live test system, I generally assign  
these to gut feel or let them go at assumptions. Automating the code  
path discovery might help provide more insight to the actual danger.  
For example, if a XML injection makes it all the way from the client  
to the third tier, that's higher risk than if it is barfed on at the  
app tier if it couldn't serialize the injection properly.

d) Lastly, map this to a sensibly sized document. Many of my code  
reviews end up being > 100 pages, which are far too hard for an  
average project to digest, let along act upon. A useful goal of such  
research is not really about a tool, but to to identify what is  
useful to large scale software engineering projects (those over say  
250,000 lines of code). I have a gut feel based upon many code  
reviews delivered, but empirical results would be nice.

That should be more than enough to keep someone busy for a few years.

thanks,
Andrew

On 18/02/2006, at 5:27 AM, shadi Aljawarneh wrote:

> Dear Sir/Madam,
> I'm a new member in Web Security Mailing List.i'm interested in the  
> web application secuirty and i'm currently doing postgraduate  
> research about web security .could you please  give me some web  
> security or web security application issues that have not solved  
> yet or need further research or any issue as tend in future.
> Actually my first glance is the validation in electronic form at Web
> system-ends(server,and client).for example,checking wither the e- 
> form is
> altered at server or client by unathorized user. is it possible to  
> hack
> web page by add command such as HTML tag has a malicious code .
> However, if you could not interest in my area could you guide me about
> other person who does.
>
> Best Regards
> Shadi
> Durham University
>
>
>
>
> ---------------------------------------------------------------------
> The Web Security Mailing List
> http://www.webappsec.org/lists/websecurity/
>
> The Web Security Mailing List Archives
> http://www.webappsec.org/lists/websecurity/archive/


---------------------------------------------------------------------
The Web Security Mailing List
http://www.webappsec.org/lists/websecurity/

The Web Security Mailing List Archives
http://www.webappsec.org/lists/websecurity/archive/