Secure nginx

Merlin merlin at mahalo.com
Sat Feb 21 02:52:10 MSK 2009


I would generally agree with these statements, especially that the
webserver's (nginx, apache) job is to serve content (resources) and that is
its job.  Even in apache, I am pretty sure there is not some magical
compiler setting for web application security.

What there generally is (in apache) is the use of a "web application
firewall" like mod_security.  Currently, there is not such a module in
NginX, but you could write one, as it is essentially a filter.  If you are
using Python with WSGI there is WSGI middleware that can act in the same
capacity.  Even with such a thing in place, you should STILL be doing
validation application side or you leave yourself open to when people get
around your web application firewall or it is down (perhaps because you
disabled it)!

Let's let the webserver serve and the applications, er, apply.

On Fri, Feb 20, 2009 at 2:15 PM, Nuno Magalhães <nunomagalhaes at eu.ipp.pt>wrote:

> On Fri, Feb 20, 2009 at 9:01 PM, Paul Greenwood <attaboy.p at gmail.com>
> wrote:
> > Is there some specific parameters that are used to lock down nginx for
> > example that might prevent sql injection or css attacks.
>
> From what i've seen, SQL injection, XSS-attacks and alike are all done
> by exploiting client-side scripting (Javascript etc) or data entered
> by users (into form fields). Avoiding client-side scripting could
> mitigate this; as would validating all user input (this one's basic);
> and escaping all code that is not part of the markup (ampersand
> entities, %-codes for URLs, that sort of stuff - think bb-code). I
> think none of this is directly related to the webserver and a big part
> of the risk lies with users not knowing how yo use their browsers.
>
> Nuno
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20090220/2a002931/attachment.html>


More information about the nginx mailing list