IncorrectResultSizeDataAccessException when uploading multiple SSVL files

[fel...@gmail.com]

Hi all,

I am using Threadfix as a vulnerability aggregation tool and I'm quite impressed with it.Good job guys!

Currently I'm trying to manually log previous pen-test findings in Threadfix, I'm attempting to do that by creating a SSVL file for each report and importing them into the associated application as a 'scan'.

However, a IncorrectResultSizeDataAccessException gets raised when I upload two SSVL to one application.

Stacktrace below:
---------------------
org.springframework.dao.IncorrectResultSizeDataAccessException: query did not return a unique result: 2; nested exception is org.hibernate.NonUniqueResultException: query did not return a unique result: 2
at org.springframework.orm.hibernate3.SessionFactoryUtils.convertHibernateAccessException(SessionFactoryUtils.java:659)
at org.springframework.orm.hibernate3.HibernateExceptionTranslator.convertHibernateAccessException(HibernateExceptionTranslator.java:89)
....

Steps to replicate:
--
1. Create a new team, with a new application.
2. Download the example SSVL file from https://github.com/OWASP/SSVL/blob/master/example.ssvl
3. Upload the example SSVL twice to new app.

Appreciated if anyone can help, or tell me that I'm doing something terribly terribly wrong. :)

Cheers,

Felix

[Dan Cornell]

Thanks for posting this - we'll take a look. ThreadFix is sometimes picky about dates for uploaded files so I could see issues uploading the same SSVL file multiple times as that could mess with the time-based aspects of merging. However even if this is the case, we should handle this more gracefully than throwing an excepition.

I've moved it into GitHub as an issue:

https://github.com/denimgroup/threadfix/issues/321

Thanks,

Dan

[Felix.S]

Hi Dan,

Thanks for the prompt reply!  I don't think the issue is caused by uploading the same SSVL files, since it was happening when I'm uploading SSVLs with different ExportTimeStamp and ApplicationTag.

You mentioned it could be related to the time-based aspects of merging, would you recommend turning merging off temporarily as a temporary method of mitigation?

Thanks for looking into this! 

Cheers,

Felix

--
Regards

Felix

[Bob Rich]

Hi Dan,

The SSVL file format is sort of coupled with manual findings in the code.  When a user creates a manual finding, ThreadFix looks for a 'Manual Scan' associated with that application to use as a container for the finding.  If one doesn't exist, ThreadFix creates it.  If it does exist, then ThreadFix just associates that finding with the scan that it found.

When SSVL files are uploaded, they are associated with the Manual Scan channel type.  However, the file upload logic actually creates a new 'Manual Scan' scan object for each upload, rather than merging all of the findings into an existing Manual Scan object.  This actually all works fine.  The exception comes when the application page is rendered and ThreadFix is looking for a unique Manual Scan to show on the page.  It finds more than one and chokes.

I got it mostly working by simply splitting the manual and SSVL channel types apart.  If memory serves there was some benefit to associating the new channel type to the manual scan vs. the SSVL scan.  I think there's also some missing channel severity references, as the critical items in the example SSVL get left in unmapped findings.

Hope that helps.

Bob