Nexpose XML API 1.1 Request and Response Examples

Document created by techeditor on Apr 9, 2011Last modified by patrick_hellen on Oct 23, 2013
Version 10Show Document
  • View in full screen mode

Overview

................................................................................ ................................................................................ .......................................................................

The XML API, like most any web based api, accepts http POSTs with specific XML requests in and produces XML responses. The requests and responses are detailed below. The sync-id is an integer you provide to allow the Nexpose console to keep track of the uniqueness of each request. It is often not requred but will be useful on a tool that is actively communicating via the API.

 

See the Code Examples for implementation tips using curl, perl and ruby.

 

 

Account

................................................................................ ................................................................................ ...................................................................

Login

................................................................................ ................................................................................ ...................................................................

 




request

1 <?xml version="1.0" encoding="UTF-8"?>


2 <LoginRequest sync-id="arbitrary_integer" user-id="my-username" password="my-password"/>

The sync-id will ensure that only a single session is opened in the case that the request is somehow sent more than once.
response

1 <?xml version="1.0" encoding="UTF-8"?>


2 <LoginResponse session-id="NeXpose provided integer" success="1"/>

The response provides a session-id. Make sure you capture this as all future requests made in this session will have to be accompanied by the session-id.

Success is a 1, anything else is a 0

 

 

Logout

................................................................................ ................................................................................ ...................................................................

 




request

1 <?xml version="1.0" encoding="UTF-8"?>


2 <LoginRequest sync-id="arbitrary_integer" session-id="NeXpose provided integer"/>

The obvious critical bit here is the session-id. The sync-id doesn't seem to be terribly useful in this case but may keep the console from spending cycles on worthless activity.
response

1 <?xml version="1.0" encoding="UTF-8"?>


2 <LoginResponse success="1"/>

Success is a 1, anything else is a 0

 

 

Scan Engine

................................................................................ ................................................................................ ...................................................................

 

Site

................................................................................ ................................................................................ ...................................................................

 

SiteListing

................................................................................ ................................................................................ ...................................................................

 




request

1 <?xml version="1.0" encoding="UTF-8"?>


2 <SiteListingRequest sync-id="arbitrary_integer" session-id="NeXpose provided integer (see login)"/>

The obvious critical bit here is the session-id. The sync-id will keep the console from generating the site listing in the case that the request is sent more than once.
response

1 <?xml version="1.0" encoding="UTF-8"?>


2 <SiteListingResponse success="1">


3   <SiteSummary id="SITE ID" name="SITE NAME" description="" riskfactor="1.0" riskscore="0.0"/>


4   <SiteSummary id="SITE ID" name="SITE NAME" description="" riskfactor="1.0" riskscore="0.0"/>


5   ...


6 </SiteListingResponse>

SiteSummary is defined in the XML schema files but basically breaks down like this:

id: the console assigned number for the site

name: the user assigned name for the site

description: may be populated by the user

riskfactor: overall site importance

riskscore: cumulative value of the risk associated with the site's devices

Success is a 1, anything else is a 0

 

Report

................................................................................ ................................................................................ ...................................................................

Assets

................................................................................ ................................................................................ ...................................................................

 

Device

................................................................................ ................................................................................ ...................................................................

Attachments

    Outcomes