[Owasp-input-api-developers] Re: goal and direction WAS: RE: [Owasp-input-api-developers] Status?

[Nik C. <ni...@ni...>]

On Tue, 2 Apr 2002, Christopher Todd wrote:

> Well, I guess that would be a reasonable question for debate.  Are we trying
> to help people write more secure web applications, or are we trying to help
> make web applications more secure?

Hi Chris,

In terms of 'helping people write more secure web applications', I think
that is the main aim of OWASP, and the filters project is one part of the
overall goal.

But, a large portion of web application developers are oblivious to the
risks that web applications pose. While it is hoped that OWASP will raise
awarness in the field, it still leaves a lot of potentially insecure sites
out there, with lazy (or unknowing) developers unwilling to implement a
filtering API (besides, there are already simple methods native to each
language to test/sanatize user input). Developers are often under time
constraints, or have many other reasons to overlook security whilst
developing a web application (pick up a book on web app development and
note how much of it is devoted to security issues).

This obviously leaves a large 'market' for server (ie. pre
web-application) filtering and intrusion detection, which is where i see a
small split within this project and two trajectories.

1. Filtering API's for developers
2. Webserver/scripting engine patches or modules for webmaster's and
server administrators.

Combined, they are obviously a powerful combination (combined with
application level intrusion detection that could be integrated within a
webserver filtering tool). Developers can take responsobility for
implementing the filtering API, and/or server administrator(s) can take
responsability for web server based filtering (these roles can often be
split widely, ie. in an outsorcing situation).

>
> For the purposes of the Input Filters API project, it seems obvious that
> implementing an API for each language will be the easiest and quickest way
> to produce something useful to the community, so long as we can agree on an
> interface that will be common across all the languages (or at least as
> common as the syntaxes of the languages will allow).  For example, once
> we've decided that the methods
>
> public String removeParentheses(String input)
> public String removeSemicolons(String input)
> public String sanitizeInput(String input, Regex exclusionPattern)
>
> (to put up a few hypothetical examples in Java syntax) are methods we need
> in the API, then it is up to the individual language implementors to figure
> out how to implement them.  That can be done pretty quickly.
>

yes, this would be simple to implement across PHP, ASP, Perl and Java.
Should we start developing a function framework and specification for
each of functions?

Perhaps a good starting point would be to firstly identify all threats
(cross site scripting, SQL injection), and then come up with relative
functions to sanatize. This will still not solve a lot of common problems
in web applications.. how many times have you seen something like:

http://www.server.com/store/account_info.php?id=12

then being able to increment id to pick up somebody else's account? I
guess this is outside of the scope of this project. There are also other
vulnerabilities such as script?include=/etc/passwd trickiness (see:
http://www.securereality.com.au/studyinscarlet.txt) that can not be easily
solved, since if the developer has not accounted for the possibility of
that variable being passed to the script, then how can they defend against
it?

An ideal option would be for the developer to explicitly allow certain
variables to a page, and all other user passed variables to be cropped
out/ignored by the web application (hard to implement in php, easy in
ASP), and then the variables that have been explicitly allowed to progress
into the web application, for the filters to be applied.

perhaps i am getting ahead of myself.

> Implementing web server plugins obviously is a much more complicated task.
> <snip>
> So to summarize, basically I agree with you, but in the long term, I think
> we should at least consider the potential usefulness of creating web server
> plugins.
>

Yes, web server plugins would be something more likely to fit into 'the
big picture' at a later date, they would have to be written in C and be
very specific to the target webserver (Apache1/Apache2/IIS).


enough ranting :)

Nik Cubrilovic
www.nik.com.au