Hot answers tagged

5

Timeouts are necessary because the internet is unreliable. We like to think of the internet as based on "connections", but that's not actually true. It's based on individual packets, which are received discretely and independently of each other. In simple terms, when the server wants to send or receive data, the server usually can't send all the data in ...


4

The advantage of authenticating at the application is having this done independently of the OS and web server, you are not mixing your implementation layers (i.e. the application's authentication and access controls don't rely on information passed on from another piece of software). Generally the advice of not authenticating at the web server level is a ...


3

Well, as I was pointed at nginx mailing list, nginx removes all environment variables inherited from its parent process except the TZ variable, so once I defined needed variables in nginx.conf env LD_PRELOAD=/usr/local/lib/libsslkeylog.so; env SSLKEYLOGFILE=/tmp/premaster.txt; keys started being recorded as expected.


3

Is it common for nginx to allow access to a shell? No. Is it common for people to create/configure websites that allow access to the shell? Kind of. Unfortunately. Does it cost nothing to check? Yes.


3

This is not strictly an Nginx problem, but rather is an issue with old versions of PHP. It has been fixed for quite a long while (I'm not sure exactly what version, but it certainly isn't a concern with PHP 7.0). The answers to this question: https://serverfault.com/q/627903/377662 Explain the underlying issue and solution in detail. The short answer is ...


3

AFAICS don't worry. This seems to be an Attack which does not affect NginX. Also I do not think this is a targeted attack, as I can see similar requests on my webservers, too. Hence it looks like some of those automated vulnerability scans to exploit something somewhere. GET requests do not have a body, so a content-length of -1 is for representation ...


2

Are these requests going to have any impact on the server? Everything has some impact but if this impact is relevant depends on how many requests these are, how much your server can handle and if these requests trigger some kind of expensive actions in the server - none of this is known. But in general such "noise" is very common on the internet so you ...


2

... this workflow is not discussed on the TLS RFC The details of the certificate validation are not part of the TLS standard. Part of TLS is only if a certificate gets requested or not. Apart from that your use can can actually be implemented by nginx. According to the documentation if ssl_client_certificate is set it will be used to a) provide the client ...


2

It is but information leaking. So on its own and at face value, don't worry about it*. On its own it's not something that could be turned into an attack. It is, however, information that an attacker could use to leverage other vectors. On the other hand, it's normally not at all difficult to mitigate, so best to pick up a few resources and start trying to ...


2

Like a normal (not same-site) cookie the Authorization header for Basic Authentication is always send with a normal HTTP request when the site is accessed and credentials are known, no matter if cross-site or not. There is no way to specify a different policy for this header.


2

I think that @Pedro has a very good and well balanced answer to your question. However, since I generally agree with your local experts, I think it is good to have some further context on why you might want to make this change. As Pedro mentioned, the issue is mixing implementation layers, and limited control becomes a real problem when you aren't ...


1

This format is used by a kind of HTTP proxy. Unless your server is actually misconfigured or hacked to be used as a proxy (you should get rid of the browser limitation and test it out), it may have the following possibilities: Someone is scanning a wide range of IP addresses for open proxies. Someone is testing the availability of an open proxy once existed ...


1

There's nothing bad in that as long as you're subscribed to any security updates list and keep an eye on vulnerabilities. Also, do subscribe to this module future releases: if you see any mentions of CVEs or fixed bugs, you may want to upgrade.


1

I agree that there is no great way to do this, but another option is to require authentication for those assets through your backend application. You can use NGINX's X-Accel-Redirect to still serve them using NGINX, but only after making a request to your application that returns the correct headers internally.


1

There is no practical or effective solution to this problem. The site is fundamentally run on the client side so whoever accesses it, will have to be able to pull the code to run it (as you mentioned) and will be able to distribute the content. Yes you can use techniques such as that which you described. There's simpler ways though, a simple authentication ...


1

Define "Too much". Nginx will handle these missing URLs very efficiently, so if they are actually impacting your servers performance then something is very wrong. Depending on your traffic profile, rate limiting could have quite a lot of impact on your server capacity, and its difficult to tune so that is effective. Also, the requests you've shown above ...


1

For DHE: openssl dhparam 2048, wait, write output to file. Use file in ssl_dhparam in nginx config. No need to keep the file secret like a private key, your server will output the content of the file to any client that supports DHE. You can reuse the file for many servers. It is considered more secure to use custom params than to use those from an RFC, ...


1

I don't think this is possible unless the HTTP Daemon itself is either in the root directory (e.g. in / rather than /var/www/html) OR if the HTTP Daemon itself is a superuser. Unless I'm misreading your text and not properly grasping what you're trying to say here, I don't think this is a possibility without the httpd being in root dir.. I've came across ...


1

You handle the upload with POST requests to a PHP script which checks the file extension and renames the file You should check the mime type. PHP have mime_content_type function for that. Even if it's possible to fool the mime header and have some code on the metadata of the file, this raises the bar for exploiting your system. If I understand correctly, ...


1

The issue is that most often people configure their PHP block like this: location ~ '\.php' { include fastcgi.conf; include fastcgi_params; fastcgi_param HTTP_PROXY ""; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param PATH_INFO $fastcgi_path_info; fastcgi_param QUERY_STRING $...


Only top voted, non community-wiki answers of a minimum length are eligible