I scanned a website with IBM AppScan and it reports multiple vulnerabilities, but when I test it manually I am not able to find the exact issue.

How is AppScan able to find vulnerabilities while I cannot find them when manually passing the same request in Burp Suite as it shows in AppScan.

  • To give us a tangible example to work from, what is one of the vulnerabilities reported by the scanner which you cannot identify using Burp?
    – R15
    Dec 15 '15 at 9:11
  • The following changes were applied to the original request: • Set path to '/index.php' • Added parameter 'read' with the following value '../../../../../../../etc/passwd' and in response i got : join("|");if(n!==w){w=n,u&&(c=c||{},c["Last Event"]=q(u));var o= {notifierVersion:H,apiKey:d,projectRoot:l("projectRoot") ||a.location.protocol+"//"+a.location.host,context:l("context") ||a.location.pathname,userId:l("userId"),user:l("user"),metaData:i(i({},l ("metaData")),c),releaseStage:e,appVersion:l("appVersion which says that is the contents of the "/etc/passwd" file was found in the response
    – Newbie1
    Dec 15 '15 at 9:29
  • i dont understand where is the passwd file which the app says has found
    – Newbie1
    Dec 15 '15 at 9:32
  • Is the scanner reporting this as a directory traversal issue?
    – R15
    Dec 15 '15 at 9:53
  • @R15 Yes It is. But i don't understand how it is possible ?
    – Newbie1
    Dec 15 '15 at 10:20

There are two possible answers.

Either: because vulnerability scanners are by their nature 'dumb', that is they are operating based on pre-configured logic, they will make a best guess at what could be wrong with something using the logic incorporated within the scanner's code and can make mistakes.

For example, if the scanner is checking for a particular string in a header (or whatever) it will flag a potential issue for any and all matching headers, which may include headers that do not have a vulnerability/weakness associated with them.

Scanners are generally pretty good at identifying 'obvious' weaknesses, but in order to be effective (i.e. not miss too much) they have to strike a balance between missing things and reporting false positives. I am not familiar with the IBM scanner...it may be possible to configure it to reduce the number of false positives (which may or may not increase the risk of missing vulnerabilities).

Or: The proxy being used to confirm the results of the scanner either:

  • Does not have the functionality available (unlikely in the case of BURP)
  • Has not been configured correctly to capture the data (entirely possible for new users)
  • The data from the proxy is not being interpreted correctly (depends on the complexity of the vulnerability and the knowledge of the user)
  • Thanks for your answer but i doubt why anyone will spend lots of dollars ie IBM app scan obviously which costs nearly $10k more or less. If they provide false positive vulnerabilities we should not rely on app scan ,instead of that one can hire one professional security engineer to find out the bugs and pay him that much as reward for months ;) is that true ?
    – Newbie1
    Dec 15 '15 at 8:54
  • 2
    @Newbie1 Scanners are good for automating and speeding up the process of discovering potential weaknesses, the number of false positives will normally be a small percentage of total 'findings' and should be relatively straight forward for someone with relevant skills/experience to rule out fairly quickly. The bottom line is that a proper assessment requires knowledge and not just a tool. Where to spend the money depends on the technical knowledge inside the organisation.
    – R15
    Dec 15 '15 at 9:06
  • I agree with @R15, the scanners are tools, not the holy grail know-it-all one-click-solution, they give you a starting point to baseline the level of risk and work on a list of tasks to lower it, but they are tools that you use to improve your system's security
    – Purefan
    Dec 15 '15 at 10:05

The simple fact is that all automated web application scanning tools have a trade-off between false positives (flagging an issue when it's not present) and false negatives (not flagging an issue that is present) and they have to make a balance between the two as part of the product development.

The way issues like the one you describe are generally coded is to make the request for directory traversal to /etc/passwd and then string match in the response for things which would commonly be present in a passwd file.

So a naive approach might be to look for things like root which could be the root user in a passwd file, but could obviously also occur in other files.

To address that the scanner can match more precise strings, but then it risks missing the finding if the string isn't exactly in the passwd file, so then it can assign probabilities to several sets of strings and decide at what level of probability to report the issue.

At the end of the day scanning is not 100% precise for all issues, which is why security testers are still in a job ...


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.