Created 01-24-2024 02:25 AM
It was observed that our application generates an error message that includes sensitive information about its environment, files, or associated data such as internal system path.
is there a way to put a custome error page in nifi
Banner Disclosure
it was observed that the application is disclosing information about internal components details through response.
Created on 03-07-2024 08:25 AM - edited 03-07-2024 08:28 AM
@sukanta
This depends on what version of Apache NiFi is being used.
In Apache NiFi 1.12 or newer, there exists the following property in the nifi.properties file for excluding the server version in HTTP responses:
nifi.web.should.send.server.version=<true or false>
The default is true when not configured.
This capability was added as part of https://issues.apache.org/jira/browse/NIFI-7321
It is best to ask unrelated question in different community questions. Asking multiple question makes it hard for other in the community to understand what question was addressed by the "accepted" solution.
Keep in mind that Apache NiFi is an open source product, so anyone can look at the source code to see what Jetty version(s) are being used.
If you found any of the suggestions/solutions provided helped you with your issue, please take a moment to login and click "Accept as Solution" on one or more of them that helped.
Thank you,
Matt
Created 01-24-2024 06:56 AM
@sukanta
I am not completely clear on what you are asking for here. Can you provide more detail?
What do you mean by "custom error page in NiFi"?
Are you referring to the NiFi bulletin Board?
Only users who are authorized for the component producing the bulletin message woudl be able to view the bulletin text via the component or bulletin board.
Thanks,
Matt
Created 02-21-2024 10:54 PM
Hi Matt,
Thanks for your reply , Here is what we wanted to achieve
for one nifi ui we are getting this error
System Error
The request contained an invalid host header [10.112.17.35:8443] in the request [/]. Check for request manipulation or third-party intercept.
Valid host headers are [empty] or:
127.0.0.1
127.0.0.1:8443
localhost
localhost:8443
[::1]
[::1]:8443
ic-alpha.nifi.tathya.in
ic-alpha.nifi.tathya.in:8443
0.0.0.0
0.0.0.0:8443
if you see the above error nifi is showing some information about the server
like ip of the server , port of the nifi etc
so we do not wanted to show all of these internal information
is there a way to change this
Thanks
Sukanta
Created 02-22-2024 08:53 AM
@sukanta
What version of NiFi are you using?
Where are are you specifically seeing this exception shown (screenshot would be helpful)?
The exception is related to the URL you are trying to use to access this NiFi. You are using an IP address that is not present as a SAN entry in the NiFi's keystore PrivateKey entry.
Thanks,
Matt
Created 02-23-2024 01:14 AM
Hi Matt,
We are using nifi 1.15.3
Yes you are right we are hitting nifi ip address with the private ip address then only we are seeing this error, where its showing all server information , is there a way to bypass it
Created 02-26-2024 08:08 AM
@sukanta
This output is normal and expected. The SubjectAlternativeName (SAN) details are available through the public key exchanged in the TLS exchange.
The TLS spec verifies the hostname against the SAN in the serverAuth certificate to protect the client from man in the middle type attacks. This information is returned to the client so that you are aware they you tried to access server XYZ, but server identified by these un-matching SANs responded.
There is nothing that can be changed on server side (NiFi) to change this behavior.
As a side note: You can use openssl to any HTTPS enabled server and get that server's serverAuth public certificate. You can then also use openssl to view the contents of that public cert which will include the SAN info. So I am really not seeing any "sensitive" information in what you have shared. If you concern is about IP addresses... Stop using them and use DNS resolvable hostnames in your SAN. Have a private and public resolvable hostnames in the SAN.
If the ask here is not about hiding this public info, but rather allowing the client to continue to connect ignoring the possible man-in-the-middle attack, that is a different question. It would be a question to ask your client provider (assuming your browser in this case?).
If you found any of the suggestions/solutions provided helped you with your issue, please take a moment to login and click "Accept as Solution" on one or more of them that helped.
Thank you,
Matt
Created 03-07-2024 03:35 AM
Hello Matt,
Thank you for your prompt response and help,
I have one more question related to this
One of our client is using apache nifi and they are running some security tool , where they hit the nifi server , and its showing the Jetty version
So is there any way we can hide the jetty version (Banner Disclosure)
for your reference I have attached one screen shot for banner disclosure
Created on 03-07-2024 08:25 AM - edited 03-07-2024 08:28 AM
@sukanta
This depends on what version of Apache NiFi is being used.
In Apache NiFi 1.12 or newer, there exists the following property in the nifi.properties file for excluding the server version in HTTP responses:
nifi.web.should.send.server.version=<true or false>
The default is true when not configured.
This capability was added as part of https://issues.apache.org/jira/browse/NIFI-7321
It is best to ask unrelated question in different community questions. Asking multiple question makes it hard for other in the community to understand what question was addressed by the "accepted" solution.
Keep in mind that Apache NiFi is an open source product, so anyone can look at the source code to see what Jetty version(s) are being used.
If you found any of the suggestions/solutions provided helped you with your issue, please take a moment to login and click "Accept as Solution" on one or more of them that helped.
Thank you,
Matt
Created 03-12-2024 12:47 AM
Thank you Matt for all your help , really appreciate this
I will try this and let you know
Created 03-07-2024 03:36 AM
Waiting for your early reply
thanks