Menu
▾
▴
owasp-input-api-developers
|
From: <Chr...@ey...> - 2002-04-03 19:17:13
|
Nik,
>But, a large portion of web application developers are oblivious to the
>risks that web applications pose.
<snip/>
>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.
Right. The point I was making is that both approaches are reasonable; I
merely wanted to prod the list into discussing which approach this project
should take, or whether both approaches should be pursued.
>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..
I think that would be an excellent starting point, using the ASAC material
(and other suitable materials) as a guide.
>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.
A good idea, and also fairly easy to implement in servlets (particularly
in the 2.3 spec - the javax.servlet.Filter class is designed to do exactly
that sort of thing).
This approach could also be implemented in the webserver plugin approach,
where a sysadmin defines the HTTP headers and form fields that will be
accepted for a given resource (that is, a servlet/JSP/PHP/Perl
script/page). I have seen webapps where the developer simply loops
through all the form fields in the HTTP request, and prints them to the
page. The developer may only be expecting the fields "name" and
"address", but then a hacker can easily construct a POST request that also
includes something sneaky like "password=Runtime.exec("cat /etc/passwd")".
<snip/>
>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).
Perhaps I am confused about some implementation details. If we are going
to create Filters that sit in front of web applications, and which
intercept all HTTP requests before they ever reach the web app, how would
we do that if not in something like an Apache module or IIS ISAPI module?
Furthermore, if we create plugins for Apache and IIS, we have just nailed
87.56% of the web server market (according to the most recent Netcraft
survey). That's pretty good coverage.
I'm not being dogmatic about any of this...the Input Filters API project
will be a valuable contribution to the community whether it produces an
API, a set of webserver plugins, or both.
Sincerest regards,
Chris Todd
Ernst & Young LLP
Security and Technology Solutions (STS)
chr...@ey...The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Ernst & Young LLP
|
|
From: vertigo <ve...@pa...> - 2002-04-04 23:23:08
|
Wait, wait, wait. There still seems to be some misunderstanding of exactly when we start filtering. This is NOT a proxy server; it is an API. We start filtering AFTER the web-server has processed the request. The proxy idea would be fine, until we started working with SSL. The idea of an "SSL Terminator" was discussed on one of the mailing lists I'm on. This would be, in effect, a man-in-the-middle attack on the SSL protocol. It works, it's dead simple, but we're not doing that. Nathan -----Original Message----- From: owa...@li... [mailto:owa...@li...]On Behalf Of Nik Cubrilovic Sent: Thursday, April 04, 2002 10:58 AM To: owa...@li... Subject: Re: [Owasp-input-api-developers] Re: goal and direction On Wed, 3 Apr 2002 Chr...@ey... wrote: > >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). > > Perhaps I am confused about some implementation details. If we are going > to create Filters that sit in front of web applications, and which > intercept all HTTP requests before they ever reach the web app, how would > we do that if not in something like an Apache module or IIS ISAPI module? As a front end proxy even before the web server. ==> [proxy] ==> [webserver] ==> [application] there might obviously be SSL problems, and the webserver would see all request's coming in from the proxy (which would mess up ACL's). There is no reason why the 'proxy' cant be on the same machine as the webserver (webserver listening on localhost, proxy forwards requests). A model for the proxy might be (again, not much to do with filter's API, just discussion) as follows, request coming in from the top and passing through. [REQUEST] [FILTER USER INPUT] [BLOCK BAD INPUT] [LOG BAD INPUT/IDS] [CHECK SANITY OF HEADERS (NORMALISE)] [FORWARD REQUEST TO WEBSERVER] And then back from the webserver to the client [FILTER DB ERROR MESSAGES] - prevent 'information leakage' [FILTER UNEXPECTED SCRIPT (PAYLOADS)] I would not be suprised if there are existing implementations of this (cant recall any). Regards, -Nik _______________________________________________ Owasp-input-api-developers mailing list Owa...@li... https://lists.sourceforge.net/lists/listinfo/owasp-input-api-developers |
|
From: Nik C. <ni...@ni...> - 2002-04-04 15:58:07
|
On Wed, 3 Apr 2002 Chr...@ey... wrote: > Nik, > > >But, a large portion of web application developers are oblivious to the > >risks that web applications pose. > <snip/> > >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. > > Right. The point I was making is that both approaches are reasonable; I > merely wanted to prod the list into discussing which approach this project > should take, or whether both approaches should be pursued. My opinion would be to focus on the API for developers first, since it is easier to implement and the main aim of the project. Am i right in saying that the API will be targetting ASP/PHP/Perl/Java? > I think that would be an excellent starting point, using the ASAC material > (and other suitable materials) as a guide. Want to start by pasting some references? I am not sure how many people we have on this list at the moment (ie. are all developers here) and if Nathan wants to get the ball rolling. > >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). > > Perhaps I am confused about some implementation details. If we are going > to create Filters that sit in front of web applications, and which > intercept all HTTP requests before they ever reach the web app, how would > we do that if not in something like an Apache module or IIS ISAPI module? As a front end proxy even before the web server. ==> [proxy] ==> [webserver] ==> [application] there might obviously be SSL problems, and the webserver would see all request's coming in from the proxy (which would mess up ACL's). There is no reason why the 'proxy' cant be on the same machine as the webserver (webserver listening on localhost, proxy forwards requests). A model for the proxy might be (again, not much to do with filter's API, just discussion) as follows, request coming in from the top and passing through. [REQUEST] [FILTER USER INPUT] [BLOCK BAD INPUT] [LOG BAD INPUT/IDS] [CHECK SANITY OF HEADERS (NORMALISE)] [FORWARD REQUEST TO WEBSERVER] And then back from the webserver to the client [FILTER DB ERROR MESSAGES] - prevent 'information leakage' [FILTER UNEXPECTED SCRIPT (PAYLOADS)] I would not be suprised if there are existing implementations of this (cant recall any). Regards, -Nik |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X