Remove last trailing slash - Haproxy 2.4.4 version - haproxy

I have haproxy 2.4.4 version. I need remover the last trailing slash, but this version doesn’t use the reqrep parameter.
I tried different conf in haproxy.cfg but none works.
Is there any way to do it??
Thanks !!

Related

Kubernetes Ingress headers single quotes

I am running into a very strange issue, I cannot set single quotes that are required by Content-Security-Policy. I assume I was running an older version of ingress which only got updated after I disabled and re-enabled it (microk8s).
nginx.ingress.kubernetes.io/configuration-snippet: |
add_header Access-Control-Allow-Origin "https://myhost";
more_set_headers "X-FRAME-OPTIONS: SAMEORIGIN";
more_set_headers "Content-Security-Policy: default-src 'self' blob:;";
Result:
skipping ingress ...: nginx.ingress.kubernetes.io/configuration-snippet annotation contains invalid word '
I've tried using x2, escaping with \, wrapping everything with single quotes and escaping, nothing worked. I'm grateful if anyone can tell me how to add single quotes to the headers or if I can avoid them and still send the CSP.
EDIT: just to be clear, this configuration used to work on older versions, right now the ingress version is v1.0.5. There is nothing wrong with the syntax or other settings.
Changes has been appeared exactly in 1.0.5 related to sanitizing annotation inputs.
You may want to check CVE-2021-25742: Ingress-nginx custom snippets. I put in bold interested for you part.
annotation-value-word-blocklist defaults are
"load_module,lua_package,_by_lua,location,root,proxy_pass,serviceaccount,{,},',"
Users from mod_security and other features should be aware that some
blocked values may be used by those features and must be manually
unblocked by the Ingress Administrator.
It seems to me your issue related to mod_security + above blocklist, that contains ' symbol.
For more details please check https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#annotation-value-word-blocklist
In order to fix your issue you should either
set the value of annotation-value-word-blocklist to an empty string ""
or
change the value of annotation-value-word-blocklist and remove ' from its list.

JBOSS 6.4.20 validates special characters like curly braces and throws 400 bad request error

I already had handled a scenario of URL tampering where I have filter with regex that compare the query strings and if there are any esacpe or special characters in it that it returns a customized message of "Invalid Parameters" which is shown on the screen.
Now this was working fine till we were using JBOSS 6.4.10 but after upgrading it to JBOSS 6.4.20, it is not even hitting the filter, somewhere JBOSS 6.4.20 is validating the request URI having escape characters/curly braces in my case and throws a 400 bad request error.
Please avoid providing solutions like upgrade to JBOSS 7 or etc. I am aware that JBOSS 7 has a flag "ALLOW_UNESCAPED_CHARACTERS_IN_URL" that resolved this issue but I cannot use JBOSS 7.
As far as I know, this behavior is related with the following security vulnerability: CVE-2016-6816 .
Try the tomcat.util.http.parser.HttpParser.requestTargetAllow sytem property. Any characters listed in the value of this property will be allowed again. Another alternative is to downgrade to JBoss EAP 6.4.12 or earlier.
Add the following in argument Standalone.conf file
JAVA_OPTS="$JAVA_OPTS -Dtomcat.util.http.parser.HttpParser.requestTargetAllow='{|}'"

TYPO3 - realurl uppercase path not working in 2.3.0 anymore

Uppercase realurl path not working after upgrading realurl from 2.2.1 to 2.3.0. Prior to the upgrade I ran this script as suggested:
https://github.com/dmitryd/typo3-realurl/wiki/Installing-and-enabling-the-extension#update-to-realurl-230-from-lower-2x-versions
... but now I can't access a record when using the uppercase path like:
domain/id/123D45WTA7/
I then get a page not found. The record and the link is working when using:
domain/id/123d45wta7/
... the original ID of the record is uppercase though: 123D45WTA7 ... and I need to access the record when entering uppercase path into the browser.
Any idea how I can access the record with uppercase again?

Mod Security SecStatusEngine

When i enabled the SecStatusEngine of mod security in their configuration file then restarting the apache shows an error
Invalid command 'SecStatusEngine', perhaps misspelled or defined by a module not included in the server configuration
SecStatusEngine command has been added to mod_security 2.8 and you're probably using mod_security 2.7.* or older.
Please upgrade mod_security or remove SecStatusEngine from your config file.

haproxy - which configuration files

I have an HAProxy install which was configured by someone who left the company. It runs on Ubuntu 10.04 and it seems to use 3 configuration files in the directory /etc/haproxy
haproxy.cfg
haproxy.http.cfg
haproxy.https.cfg
I don't see the point in using the haproxy.https.cfg file as I believe (in our configuration) it can all be configured from a single haproxy.http.cfg file but when I remove that httpS file it complains bitterly and refuses to run. My question
Is this the standard configuration haproxy uses or if not, I can't find a reference to the "S" file anywhere. Can anyone suggest how HAProxy concludes it should use it?
Thanks
The very answer to your question: your haproxy is simply launched with those three config files ( -f haproxy.cfg -f haproxy.http.cfg -f haproxy.https.cfg, maybe from /etc/init.d/haproxy but mileage varies depending on your distribution ).
If you remove the file, of course it will complain.
This is not particularly standard, but ain't bad either, it helps structuring the conf rather than having a very long file.
The task of the .https version will certainly be to redirect the https traffic towards a service that can handle HTTPS (stunnel or nginx usually), since haproxy cannot terminate ssl connections. (stunnel has to be patched, see on the haproxy page)
If you want you can merge those files into one or two, just find out how haproxy is launched (check for init.d or let us know which distribution) and fix it appropriately.
I believe that it is only /etc/haproxy/haproxy.cfg that is used by default.
This may be of use to you (1.4 configuration reference):
http://haproxy.1wt.eu/download/1.4/doc/configuration.txt