Re: Blind SQL injection (confirmed) (216 Views)
Reply
Occasional Contributor
danny.chung
Posts: 2
Registered: ‎08-05-2009
Message 1 of 5 (654 Views)

Blind SQL injection (confirmed)

I did a search on my site and get the following


Blind SQL Injection (confirmed)..


http://www.mysite.com/xxx/xxx/Query.aspx (Post) _ EVENTTARGET=&...... (why I can't copy it from webinspect??)


What can I suggest to my developer ?


Also there is an option which can send to "SQL injector" ... will if help to further identify the problem and


get all the data from there?


 


Thanks


Danny

Please use plain text.
Respected Contributor
HansEnders
Posts: 585
Registered: ‎07-01-2008
Message 2 of 5 (654 Views)

Re: Blind SQL injection (confirmed)

Danny;


 


The moniker, "confirmed" indicates that the WebInspect SQL Injection Intelligent Engine was not only able to elicit logic changes in the Response via TRUE/FALSE probes, but that it was also able to make SELECT queries.  Looking at the HTTP Request information in the WebInspect UI should reveal the name of the attacked parameter since the last injection script being inserted should be high-lighted in a dark blood red.  I must point out that their are a number of probes sent by this engine, yet the UI is only capable of storing and displaying the final one to you.


WebInspect's right-click menu offers a "Copy URL" (great for GETs, not useful for POSTs) and a "View in Browser", neither of which help you copy the POST Request.  The best method for a POST would be to right-click the session > Tools > HTTP Editor.  This loads that request editor tool with the original Request ready for replay or manual hacking, and that UI allows you to copy whatever you need.


In addition, WebInspect 8 now offers a "Generate Session Report" via the right-click menu.  This particular option is only available from within the Site Tree pane, not the Vulnerabilities tab.  This feature allows you to run a very small Report for only the selected session.


 


To validate either a "SQL Injection (confirmed)" or a "Blind SQL Injection (confirmed)", you will want to start with the SQL Injector.  To load the original request, right- click the session > Tools > SQL Injector.  This saves you the trouble of rebuilding the Request in the tool if launched separately from the Tools menu.  If the SQLi were named "possible" then the SQL Injector would not be appropriate as the engine found differing responses for TRUE/FALSE but could not finalize with SELECT statements.


Now that you have the session loaded into SQL Injector, check under the Edit menu > Settings to ensure the appropriate Login Macro and/or Authentication settings carried over automatically from the WebInspect scan's settings.  This is another nice addition with WebInspect 8.  You can also switch these items around here, if there is an alternate Macro you would prefer to use.  I generally like to also configure the use of an intercept proxy such as using 127.0.0.1:8080, launching our Web Proxy tool separately from the Tools menu.  The proxy allows me to review what actually occurs during the injection actions, and helps identify if session state was not being established, et al.


Once you have the SQL Injector configured and ready, click the green "Send" button to the upper right, if prompted choose to "Filter" the original SQLi script from the original Request, and watch the Status bar in the approximate center of the screen as all of the page's parameters are re-tested.  If the status bar indicates vulnerable, then proceed to the buttons on the upper left that become available, either  "Pump Data" (get all), or progress through "Get Tables" > "Get Columns" > "Get Data".   There is a more detailed walk-through of this process in the Injector's Help guide.


If the status bar indicates injection is "not possible", then either session state was not established by the injector or there are other complications preventing the extraction of the data via SELECT statements.  There still exists the issue of unvalidated user input by the application, and it is quite likely that other injection methods are possible besides data extraction, such as DROP, UNION, INSERT, UPDATE, et al.


If you are successful in extracting data, use the SQL Injector's File menu to save the *.SDF file.  This is a SQL data file which constitutes a local copy of the stolen database, and it may be further manipulated or investigated using MS SQL Studio Express.


-- Habeas Data
Please use plain text.
Occasional Visitor
Jake_Rialto
Posts: 2
Registered: ‎06-17-2011
Message 3 of 5 (331 Views)

Re: Blind SQL injection (confirmed)

This text should be included in all SQL injection and blind SQL injection vulnerability reports!

 

+1 for the poster too, great stuff.

 

To validate either a "SQL Injection (confirmed)" or a "Blind SQL Injection (confirmed)", you will want to start with the SQL Injector.  To load the original request, right- click the session > Tools > SQL Injector.  This saves you the trouble of rebuilding the Request in the tool if launched separately from the Tools menu.  If the SQLi were named "possible" then the SQL Injector would not be appropriate as the engine found differing responses for TRUE/FALSE but could not finalize with SELECT statements.

 

Now that you have the session loaded into SQL Injector, check under the Edit menu > Settings to ensure the appropriate Login Macro and/or Authentication settings carried over automatically from the WebInspect scan's settings.  This is another nice addition with WebInspect 8.  You can also switch these items around here, if there is an alternate Macro you would prefer to use.  I generally like to also configure the use of an intercept proxy such as using 127.0.0.1:8080, launching our Web Proxy tool separately from the Tools menu.  The proxy allows me to review what actually occurs during the injection actions, and helps identify if session state was not being established, et al.

 

Once you have the SQL Injector configured and ready, click the green "Send" button to the upper right, if prompted choose to "Filter" the original SQLi script from the original Request, and watch the Status bar in the approximate center of the screen as all of the page's parameters are re-tested.  If the status bar indicates vulnerable, then proceed to the buttons on the upper left that become available, either  "Pump Data" (get all), or progress through "Get Tables" > "Get Columns" > "Get Data".   There is a more detailed walk-through of this process in the Injector's Help guide.

 

If the status bar indicates injection is "not possible", then either session state was not established by the injector or there are other complications preventing the extraction of the data via SELECT statements.  There still exists the issue of unvalidated user input by the application, and it is quite likely that other injection methods are possible besides data extraction, such as DROP, UNION, INSERT, UPDATE, et al.

 

If you are successful in extracting data, use the SQL Injector's File menu to save the *.SDF file.  This is a SQL data file which constitutes a local copy of the stolen database, and it may be further manipulated or investigated using MS SQL Studio Express.

Please use plain text.
Occasional Visitor
back2crack
Posts: 1
Registered: ‎03-13-2014
Message 4 of 5 (218 Views)

Re: Blind SQL injection (confirmed)

Hi, I have 43 parameters in a session. And the sql injector is processing all the parameters. After processing 43 parameters, it is starting from the first one again. Could you please help me understand what is happening here. Thanks.
Please use plain text.
Respected Contributor
HansEnders
Posts: 585
Registered: ‎07-01-2008
Message 5 of 5 (216 Views)

Re: Blind SQL injection (confirmed)

back2crack, if the tool is misbehaving, you would be better working on it with the HP Fortify Support team. Check http://support.fortify.com on ways to reach them.

-- Habeas Data
Please use plain text.
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation