Re: [WEB SECURITY] Paper draft: Enough With Default Allow in Web Applications!

["Ivan Ristic" <ivan.ristic@xxxxxxxxx>]

Colin,

Thank you for your thoughtful response.

1. I completely agree about the need to define parameter types only
once. I've personally used a "data dictionary" approach when building
applications, and this is exactly the concept we need here in order to
make models simpler. I've added this to the second version of the
paper. As a separate helper mechanism, we may want to define aliases
for many regular expression patterns.

2. I've also changed "behaviour" to "behavior" in the markup.

3. While I agree that specifying allowed remote IP addresses,
date/time constraints, rates and such would be useful, such
information goes beyond the scope of what we are currently trying to
achieve. Those are all deployment-time concerns, which cannot be
foreseen by application developers or shared among users. I agree that
all these things should be implemented by web application firewalls,
but in a separate layer on top of an application model.

PS. I've published the revised version of the paper today:
http://blog.modsecurity.org/2008/07/enough-with-d-1.html


On Thu, Jul 17, 2008 at 4:57 PM, Colin Watson <colin@xxxxxxxxxxxxxx> wrote:
> Ivan
>
> Thank you for publishing your thoughts.
>
> I think the proposed model looks like it could act as a bridge between some of these tasks, documenting the essence of the application.  I agree that web servers should not have to handle all 'inappropriate' requests since this adds load, degrades performance and increases the risk of information disclosure.  People compare 'buggy software' to 'bridge building', but bridges don't have to withstand improbable events - web applications do.
>
> Web applications that do specify their external interfaces would be great.  In particular, much of this could be undertaken at the design and development stages - the creation of a Design Profile.  Some of the major resources can be identified early in the project, but as the project proceeds, additional resources like style sheets, images and other file downloads can be identified.  The proposed use cases all seem valid.
>
> Some further thoughts:
>
> Application profile comparison
> ------------------------------
>
> If we had both a (unautomated) Design Profile and a generated Traffic Profile, I could envisage a useful tool which would identify deviations of one from the other.  A Design Profile could be used by the profile identifier as well as traffic analysis.
>
> The Design Profile could certainly reduce uncertainty - particular parameter confidence of known resources.
>
>
> Closing the loop
> ----------------
>
> There are many formal and semi-formal methods for software development.  The use of UML with Object Constraint Language (OCL) is often a good starting point.  Some tools can export designs into Perfect or Z (pronounced zed) to generate hypotheses which can be mathematically proven, and the generated code should posses.  There are methods to generate code directly from such models and languages.
>
> So, requirements engineering leads to a design that produces a model which is used to create a Design Profile and formal specification (e.g. in Z).  From these, the code testing can be designed and the code developed.  The actual Traffic Profile and Design Profile can be used to detect anomalies, or for modification that have missed the change control processes.
>
>
> Model properties
> ----------------
>
> Many parameters are shared across multiple resources, and I wonder if these could be aliased as some pan-application parameters and then selected within each resource?  This would save repetition and reduce errors in manually generated profiles.
>
> Would it be useful to allow resource identifier wildcards e.g. for many documents in an online repository:
>
>   <resource name="/int/store/*.xls" />
>
> "what applications are willing to accept from the outside world" - if we specify request method, preconditions could also include port, domain and whether SSL is required, or perhaps these could be higher-level application properties.  Preconditions (in a Design Profile) could maybe be defined for properties like:
>
> - allowed remote IPs
> - allowed user agent strings
> - date/time restrictions
> - permitted rate of use
> - user authentication requirements
>
> since these are likely to be understood by other tools which may use the generated profile (e.g. scanners, WAFs, network firewalls).
>
>   <usergroup name="public">
>    <behaviour>
>     <preconditions>
>         <match var="remote_addr" value="*" />
>
>     </preconditions>
>    </behaviour>
>   </usergroup>
>
>   <usergroup name="staff">
>    <behaviour>
>     <preconditions>
>          <match var="remote_addr" value="10.11.12.*" />
>          <temporal days="2,3,4,5,6" hours="8-18" />
>     </preconditions>
>    </behaviour>
>   </usergroup>
>
>
>   <resource name="download.php" suffix="^/">
>    <behaviour>
>      <preconditions>
>       ...
>       <usergroup value="staff" />
>      </preconditions>
>     </behaviour>
>      ...
>
>    </behaviour>
>   </resource>
>
> But this might need some way to combine rules A and B, A or C.  It might not be impossible for the traffic tool to produce a usergroup based on the actual traffic it has seen:
>
>   <usergroup name="analysed">
>    <behaviour>
>     <preconditions>
>          <match var="remote_addr" value="*" />
>          <match var="user_agent" value="M*" />
>          <temporal days="1,2,3,4,5,6,7" hours="0-23" />
>     </preconditions>
>    </behaviour>
>   </usergroup>
>
> or even produce these per resource or directory?
>
> A future extension might be to extend the use of the preconditions and allow these to be used to enforce some basic business logic.  Although Web 2.0 technologies have allowed developers to bypass a step-by-step process, there are still many instances where sequencing is important.
>
>
> Some further reading on formal methods
> --------------------------------------
>
> Modelling Web Application Architectures with UML
> http://www.uml.org.cn/UMLApplication/pdf/webapps.pdf
>
> Generating commercial web applications from precise requirements and formal specifications
> http://www.eschertech.com/papers/wwv05paper.pdf
>
> Bridging the Gap Between Web Application Firewalls and Web Applications
> http://www.cs.kuleuven.be/~frank/PAPERS/fmse06.pdf
>
> Using security patterns to combine security metrics
> http://www.cs.kuleuven.be/~riccardo/uploads/docs/heyman-secse08.pdf
>
> Provable Protection against Web Application Vulnerabilities Related to Session Data Dependencies
> http://www.cs.kuleuven.be/~lieven/research/publications/docs/ieee-tse08-preprint.pdf
>
> The World Wide Web Virtual Library: The Z notation
> http://vl.zuser.org/
>
> WWM: A Practical Methodology for Web Application Modeling
> http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/proceedings/&toc=comp/proceedings/compsac/2002/1727/00/1727toc.xml&DOI=10.1109/CMPSAC.2002.1045070
>
>
> Colin
>
> PS 'behavioUr' might upset N.America
>
> ----------------------------------------------------------------------------
> Join us on IRC: irc.freenode.net #webappsec
>
> Have a question? Search The Web Security Mailing List Archives:
> http://www.webappsec.org/lists/websecurity/archive/
>
> Subscribe via RSS:
> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>
> Join WASC on LinkedIn
> http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>
>



-- 
Ivan Ristic

----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/archive/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]

Join WASC on LinkedIn
http://www.linkedin.com/e/gis/83336/4B20E4374DBA