Forum: NGINX Secure nginx

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Paul G. (Guest)
on 2009-02-20 23:23
(Received via mailing list)
Is there some specific parameters that are used to lock down nginx for
example that might prevent sql injection or css attacks.  I have read
"Apache Security" and "Preventing Apache Web Attacks" but not quite sure
how
to apply that knowledge to nginx.  I would appreciate any suggestions.
Thanks
Nuno Magalhães (Guest)
on 2009-02-21 00:32
(Received via mailing list)
On Fri, Feb 20, 2009 at 9:01 PM, Paul G. <removed_email_address@domain.invalid>
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
Merlin (Guest)
on 2009-02-21 02:03
(Received via mailing list)
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.
Dave C. (Guest)
on 2009-02-21 09:20
(Received via mailing list)
Both of those attack vectors relate to web applications, not web
servers. Nginx and apache do their part to make sure any data proxied
through them to the web application is well formed. However it is the
applications job, not the web servers, to make sure it behaves
correctly in the presence of untrusted data.

Cheers

Dave
This topic is locked and can not be replied to.