The value of this header should be of the form “ accesskey= secretkey=” for it to be correctly parsed. When calling any Tenable.sc endpoint an additional header of “x-apikey” can now be passed in. When a user attempts to authenticate to Tenable.sc with an API Key the Access Key used is logged for identification purposes in a similar manner to logging that utilizes the authentication token. Furthermore, a System Administrator level account can generate/delete an API Key of any user in the system. The API Key can be generated/deleted by the user who wishes to authenticate to the system in this manner as well as any user who has permission to manage that user’s password. An API Key is assigned to a single user and allows that user to authenticate to any Tenable.sc endpoint without having to first authenticate to the system and receive a token. UsageĪn API Key is another method of authentication for a user much like a password. This documentation uses “API Key” in the singular to refer to a unique combination of an Access Key and Secret Key. The combined Access Key and Secret Key that uniquely identifies and authenticates a user of the Tenable.sc system. This information is not visible after generating an API Key. One half of an API Key that is used in conjunction with the Access Key to allow authenticate to the system. This information is visible on a users’ information as well as in the system logs. One half of an API Key that is used for identifying which user is accessing the system. NomenclatureĪn administrator or organizational level account on a Tenable.sc system. Furthermore, a Tenable.sc system administrator will be able to toggle this functionality on and off system-wide. This API Key is similar to Tenable.io’s API Key where it is divided into two parts (an “Access Key” and a “Secret Key”) and allows access to the API Endpoints without requiring an authentication token to be generated previously and used in the header.
#How to use nessus api code
The code is relatively simple and I hope to inspire everyone.In Tenable.sc 5.13.0 users will be able to authenticate to the system by using an API Key. The above code implements a simple host-based vulnerabilities result sorting, and outputs the results in the form of a dictionary list. In daily use, host-based is a commonly used dimension. Respon = requests.get(url, headers=header, verify= False ) # Get host vulnerability information def get_vul_by_host (scan_id, host_id) : # call
Host_detail] = get_vul_by_host(scan_id, host) # Traverse the host list and generate results for host in host_list: = requests.get(url, headers=header, verify= False ) # Get scan results (based on host) def get_scan_detail_baseon_host (scan_id) : # Results, host vulnerability dictionary list Of course, you can also take out all the values in the following way. The method I take here is to traverse the attributes, and then determine whether it is the information I need according to the attribute_name, and take the corresponding attribute_value into my own output dictionary. Vul_detail = attrĬontinue # Vulnerability description elif attr_name = 'synopsis' :Ĭontinue # Vulnerability details elif attr_name = 'description' :Ĭontinue # vulnerability level elif attr_name = 'risk_factor' :Ĭontinue # Vulnerability description elif attr_name = 'solution' :Ĭontinue # Vulnerability release time elif attr_name = 'plugin_publication_date' :Ĭontinue # Vulnerability discovery time elif attr_name = 'vuln_publication_date' : # Traverse attributes to generate results for attr in result: Respone = requests.get(url, headers=header, verify = False ) # Vulnerability discovery time'discover_time' : '' # Vulnerability release time'release_time' : '' , # Vulnerability details'vul_detail' : '' , # Vulnerability description'vul_intro ' : '' , # Get vulnerability details according to id def get_vul_detail (plugin_id) : As usual, let’s take a look at the return value of this interface. The interface for querying vulnerability information details is: If you want to know more about the details of the vulnerability (note that the details of the vulnerability itself have nothing to do with this scan).
You can see that what is returned is a dictionary list, the information contained is an overview of this missed scan, the content is the statistics of the number of vulnerabilities and the basic information of the vulnerabilities, including a plugin_id, which can be used to obtain the details of the vulnerabilities.įrom the details of the scan, we can only see the overview of this vulnerability.
let's take a look at what is returned in the vulnerabilities' field.
The acquisition of the missed scan result is related to the information in it.ġ. # monitor the status of the specified task def listen_scan (scan_id) : # call/scans/ interface, in addition to returning the status of the scan task, A vulnerability list response and a host list response are also returned.
0 kommentar(er)
