[WEB SECURITY] web security
Andrew van der Stock
vanderaj at greebo.net
Fri Feb 17 14:29:25 EST 2006
My $2.50 (= my posts are rarely short, and therefore $0.02 will not
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.
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
> 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
> Durham University
> The Web Security Mailing List
> The Web Security Mailing List Archives
The Web Security Mailing List
The Web Security Mailing List Archives
More information about the websecurity