Can anyone please tell me why the following URL returns a 406 error:
http://kolek.to/functions/remote-upload.php?url=http%3A%2F%2Fben-major.co.uk%2Fhosting%2Fbm-equipment%2Faxe-2.jpg&item_id=2
Removing the ?url= parameter seems to make everything fine:
http://kolek.to/functions/remote-upload.php?item_id=2
For your reference, the content of remote-upload.php is as follows:
<?php
require_once('../models/api.php');
$request_url = urldecode($_REQUEST['url']);
$item_id = $_REQUEST['item_id'];
echo $item_id;
?>
I think that this is due to the security filter from your server (I see in the response header that is Apache).
In your case is Apache mod_security that is turned on by default. While you can use the following to diagnose the problem (turning the filter off should resolve the issue) by running this command on the server:
SecFilterEngine off
BUT do this only for checking if the problem is the security filter, I discourage to leave the filter off (danger of injection and spam attacks).
If you see that is the filter that is the cause of the problem, try to put your request in the whitelist:
HERE you can find the guide and HERE is the main website.
Related
I recently have tried to update settings on the server of a non-profit website I host and have run into configuration issues in regards to the Permissions Policy. I haven't found many examples of the proper use-case and syntax to use for this setting and thus have run into errors in the Chrome console for cimarronoutdoors.org. Here is the Permissions Policy I am trying.
Header always set Permissions-Policy "geolocation=();midi=();microphone=();camera=();fullscreen=(self);payment=()"
In the console it returns the following.
Error with Permissions-Policy header: Parse of permission policy failed because of errors reported by strctured header parser.
I have tried only listing items from the link below and limiting it to a few to see if that might be the issue but I can't get the error to go away.
https://github.com/w3c/webappsec-permissions-policy/blob/main/features.md
Any advice on this issue would be greatly appreciated.
Server OS: Ubuntu 16.04.7 LTS
Permission Policy set in site conf file.
I found out that the scheme changed from microphone 'none'; geolocation *; payment https://*.paypal.com; to microphone=(),geolocation=*,payment=("https://*.paypal.com").
At the moment the below code is valid, so it won't produce nor the "We didn't detect a viable policy." on securityheaders.com neither the "Error with Permissions-Policy header: Parse of permissions policy failed because of errors reported by structured header parser." in Google Chrome console.
Keep in mind to properly escape double quotes in configs, use commas instead of semi-colons (as mentioned also below) and use the "new format".
nginx.conf example:
add_header Permissions-Policy "accelerometer=(),autoplay=(),camera=(),encrypted-media=(),fullscreen=*,geolocation=*,gyroscope=(),interest-cohort=(),magnetometer=(),microphone=(),midi=(),payment=(\"https://*.paypal.com\" \"https://*.barion.com\"),sync-xhr=*,usb=(),xr-spatial-tracking=()" always;
apache.conf example:
Header always set Permissions-Policy "accelerometer=(),autoplay=(),camera=(),encrypted-media=(),fullscreen=*,geolocation=*,gyroscope=(),interest-cohort=(),magnetometer=(),microphone=(),midi=(),payment=(\"https://*.paypal.com\" \"https://*.barion.com\"),sync-xhr=*,usb=(),xr-spatial-tracking=()"
Use commas instead of semicolons as delimiters.
See example here:
https://www.w3.org/TR/permissions-policy-1/#policy-directive
The way to creating Permission-Policy has changed.
You have to add parentheses around lists, use commas instead of semi-colons, and add double-quotes around most strings:
fullscreen=(self 'https://example.com'), geolocation=*, camera=()
Here's a link: Appendix: Big changes since this was called Feature Policy
I am trying to confgiure a re-write action on our Citrix Netscaler load balancers to add in the Report-To response header as we want to setup Network Error Logging but struggling with the Syntax.
The example I have is below, (I add in our subdomain details) but it's failing to work - Im confident that the process is correct as we have added in a HSTS header, it's just the syntax we think is out:
This is the syntax we are using:
Report-To: {"group":"default","max_age":31536000,"endpoints":
[{"url":"https://{subdomain}.report-uri.com/a/d/g"}],"include_subdomains":true}
This is the error:
Expression syntax error [^{"group":", Offset 0]
Has anyone added this header in before on a netscaler / or have an idea where we may be going wrong ?
Many thanks in advance
I'm pretty sure you are not escaping the " correctly. You can directly run the commands below on the CLI to add the expression to your NetScaler
add rewrite action insert_report_to_header insert_http_header Report-To q<"{\"group\":\"default\",\"max_age\":31536000,\"endpoints\":[{\"url\":\"https:\\/\\/{subdomain}.report-uri.com\\/a\\/d\\/g\"}],\"include_subdomains\":true}">
add rewrite policy report-to-header true insert_report_to_header
I came across 404 error a few times and i have difficulties in debugging this kind of problem.
What is the strategy and tools available to analyse such problems (firebug, logs...).
How to differentiate and fix the cause ?
page not existing ,wrong path , redirection and rewriting ,server problem ...
404 error code means that a file is not found for whatever reason.
Just check that the file exists and that the path you use is right.
You can analyse sent requests and received responses headers and body in your browser's developper console if you want more details about why some request failed.
I've seen hundreds of pages explaining how to create custom error pages in Apache 2 server. My question is different. I have a web application running in Apache (it is a ISAPI DLL, but it could also be a CGI executable). My application can handle internal server errors and generate a detailed error message (for instance, include a full stack trace), included in the response together with error code 500. AFAIK, Apache just let me use redirection in order to display custom error messages: http://httpd.apache.org/docs/2.2/custom-error.html
HTTP spec (RFC 2616 - section 10), not only allows but also recommend that detailed error message should be included in the BODY section of the response in case of error code > 500.
Link: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.5
Seems that Apache won't let my custom error message go to the browser, and always replace it with its own internal error message and I believe that it is not the correct behavior, based on RFC 2616.
So my question is: Is there any setting in Apache server that will let my custom message go to the browser? Or, is there anything that can be done in my application that will instruct Apache to send my custom error message (something like some specific header field in the response)?
More on the subject:
When my ISAPI application returns error code 500, with other error information in the response body, Apache replaces it with its standard "500 Internal Server Error" message/HTML content, and inside Error.log file I can see the "useless" "Premature end of script headers" message. I'm deeply sure that my headers are fine, including the Content-Type field.
If I replace the 500 error code with any other server error code (e.g. 501) it works flawlessly and my response goes to the browser as is. The same header is sent to the Apache server, only the error code is different (501, instead of 500). With this test result in mind, one of these two must be true:
1- Apache requires some specific header field when status code is 500
2- Apache won't let custom error messages with status code 500 go to the browser.
I don't see any other alternative.
I think you're conflating two questions. You can generate a 500 response with a CGI script and include your custom body. Or you can override any 500 with any resource you want.
If you're failing to do the former, it's likely because of some subtle thing in the ISAPI interface between Apache and your module. Desk-checking the code says you should be able either set the pseudo
Status: 500
Header, or basically return any ISAPI error and end up with a 500 and your custom body.
Apache has two notions of a status code -- the one in the status line (r->status) and an error code returned separately from the module that handles the request (return HTTP_INTERNAL_SERVER_ERROR, return r->status).
When the former is used as the latter is when the custom error messages get lost. All of that happens in./modules/arch/win32/mod_isapi.c in Apache. Whatever is going on, it is ISAPI unique.
We are getting a 405 error and the following exception from IIS7 when attempting to apply a ResponseStreamFilter to HttpResponse.Filter:
HttpException:
The HTTP verb POST used to access path '/app/Thing.asmx/Command' is not allowed.
We are applying the filter by using an HttpModule with code like this:
var rfs = new ResponseFilterStream(HttpContext.Current.Response.Filter);
rfs.TransformStream +=
new Func<System.IO.MemoryStream, System.IO.MemoryStream>(ProcessStream);
HttpContext.Current.Response.Filter = rfs;
Log("Response stream filter applied correctly.");
All of the code in our HttpModule works just fine... it's all wrapped in a try-catch just to be safe and isn't throwing any exceptions, and diagnostic logging like the last line above is working correctly.
But it looks like our ProcessStream method in the above code is never being called. If we apply the filter to HttpResponse.Filter at all, IIS throws the 405 exception before our filter begins processing.
Our code has worked before on several similar systems, so we suspect IIS/machine configuration on this specific server is responsible. What could be causing this?
The most commonly reported cause for a 405 error in a situation like this seems to be using Url.Rewrite. (The HTTP verb POST used to access path '/test.html' is not allowed) However, we are never using a Url.Rewrite.
Another commonly reported cause is trailing slashes in the request URL. (HTTP 405 on Error on HTTP POST IIS ASP .NET) But as mentioned above, the URL being requested does not end with a slash.
The app pool is running .NET 4.0 in a Classic pipeline (jQuery AJAX post receives 405 error (HTTP verb POST not allowed)), but our code has run without issue on many other systems under a Classic app pool, so there would still have to be something unique to this server's configuration. Changing to Integrated pipeline breaks the application our code is filtering, so that's not a possible workaround anyway.
Turns out, it was a very obscure IIS bug:
http://support.microsoft.com/kb/980368
The ExtensionlessUrl handler (*.) was incorrectly getting involved with the request instead of just the WebServiceHandlerFactory (*.asmx) as expected. The workaround was:
Manually deleting the ExtensionlessUrl handler entries from the web application's handler mappings
Manually moving the ExtensionlessUrl handler entries under anything you actually expect to be hit
Adding a web.config entry under system.webServer/handlers to remove the ExtensionslessUrl handler as needed (we went with this option to make sure it got included with app demployment)
We had to burn a Microsoft support ticket on this one, since there's no way we would have figured this out in any reasonable timeframe. Hopefully this helps someone else.