Security Risks on "Verify=False"/ignoring certificate for Scripting API Call
Completed
I created a similar post a while back about creating a script that will properly authenticate using the server's SSL certificate. I have still been wrestling with that, but figured this question would be better suited as a separate post.
Using Python and the "requests" library, I can pull information via the API that is helpful for our documentation. For example, I've successfully created a script using
https://127.0.0.1:7001/rest/v2/devices?_format=CSV&_with=name%2Cvendor%2Cmodel%2Cmac%2Cid%2CphysicalId%2Curl'
to automatically create a spreadsheet document of all of the camera details.
If I use
requests.get('https://127.0.0.1:7001/rest/v2/devices?_format=CSV&_with=name%2Cvendor%2Cmodel%2Cmac%2Cid%2CphysicalId%2Curl', auth=basic, verify=False)
It works fine.
Since this is a simple HTTP call via loopback and not an ongoing connection to the server, is it susceptible to security risks? Do I even need to worry about the SSL certificate if used only for collecting information and not used as an ongoing connection?
-
Hi Rhaphiel Molinar,
Thanks for your question. In fact, this is not a security issue at all.
1) First, we need to understand what public/private/self-signed certificates mean and how they work.
The certification can be thought as an ID identification like your social security card or passport.
Within your country, likely both social security card or passport are both valid.
However, if you go abroad, then only passport would be treated as a valid one. So private or self-signed certificates is the social security card, and a public certificate is the passport.That being said, you can either use a private one or public one, depending on what your use cases or environments are. If you are using the python module - requests, it would required a publicly trustable certification by its nature.
2) If you are on the Internet, while the verification is enabled and request the validation, meaning you are asked to provide the valid certificates. So your certificates are mandatory to be public trusted one. That being said your certificates are necessary to be signed and issued by a trusted and public organization. (like your passport has to be issued by a country)
3) If you are within your own intranet, you can use the certificates that is valid within your domain. You can always publish your private certification for yourself. This is similar to you can use the social security card in your country and pass the validation.
4) verification = False does not mean breaking the security, but just ignore the validation procedure.
This could be due to you already confirm the site is trustable, or there is no necessary to validate. For example, just a sandbox or just for test purpose, or just not required.I believe DW has the supported article to replace the "DW-self-signed" to a public acknowledged one or a privately trustable one. If not, you may refer to Nx Witness one here.
BTW, you are using the auth=Basic, this instead needs an improvement. DW/Nx has provided the Oauth2 and session authentication mechanism, so you are recommended to use that for any authentication.
Long story in short, this is not a security issue, but your own option if you are going to pay for the public certificates to be a worldwide trustable domain. (i.e. public and certified organization signed certificates)
0 -
- Authorized Reseller
The DW article is effectively a copy/paste of the Nx one. I will admit that SSL certs are something of a headache for me to fully grasp despite my best efforts. I've noted in my attempts to better understand it that there is concern for MITM attacks, so it was something that became a concern of mine, especially if I was trying to write scripts that was with the intent of providing to our team to use.
Auth=Basic being used is how a lot of the API calls via Python have been used, so I'll have to investigate the use of Oauth2 and see if I can figure out how to implement that instead. I'm sure its a relatively simple adjustment.
I've tried to point the validation of the SSL both by the self-signed cert on the server as well as importing the Certifi package, but the validity fails within the chain through every method. I anticipate this to be an item to investigate on my own, but with the script working by ignoring it, it then became a question if I could ethically ignore the validation of it to simplify the script for myself. It sounds as if if I adjust the script to use Oauth2 instead, that there shouldn't be any issue and I could ethically use the script.
0 -
Hi Rhaphiel Molinar,
It is correct but also not fully correct.
Replacing the SSL certificates can help to let the system or verification work successfully within your domain.
For example, you replace the SSL on the "https://127.0.0.1" host with a certified one (either public or DW) , then verfiy=True should be all working in theory.However, if you are working with something like cloud API or relay the API via cloud, you would still need to take care of the certificates, but as far as I can see, it seems the cloud portal of DW (https://dwspectrum.digital-watchdog.com/) is using the publicly trusted certificates.
But again, this is not a security issue, but your preference of the certificates. This is out of DW Spectrum scope but the network security and IT security. You may be suggested to consult with your IT to solve this from the security configuration side.
Thanks.
0 -
- Authorized Reseller
I actually found some documentation that I never saw before that has actually given me everything that I need. It was a hyperlink way down in the API Information.
Since this allows me to use HTTPS without immediate rejection (with the inclusion of the bearer tokens), I can use this instead of my previous method.
You are correct in it being out of the scope of anything that our support team is expected to do, but I create scripts to supplement our team with easy methods to collect information that isn't available from the software natively. For example, I think having an export of camera list information similar to the license export would be fantastic for not only us, but our customers as well (for proper documentation of their sites). Since these types of QOL functions are generally low priority for the development team and unlikely to be included when there are more important items to address, I like to try to create these scripts for our team so we can still have the functions available to some degree. This makes it easier for less experienced support agents to get necessary information without having to understand how the API tool works.
0 -
Hi Rhaphiel Molinar,
Thanks for your extra feedback, appreciated this.
It is glad to hear that you have found the proper resource to help you complete your task better.We will create some simple tools while available and upload them to the GITHUB if we have any.
Of course, we still encourage any of our users, if they are willing to study or try the API, they will find the tool is so useful and of course, we will offer the help from here.Thanks again and appreciate your feedback.
0
Please sign in to leave a comment.
Comments
5 comments