Verb tampering issue from app scan

[Thomas Douglas]

Hello, we have a security team that uses IBM AppScan (9.0.3.9) to scan our products for security vulnerabilities. It was recently discovered that our Jira Software instance (7.10.0) has five verb tampering issues (Authentication Bypass Using HTTP Verb Tampering). Has anyone run across this? If so, how did you address it? Or, possibly determine that it is a false positive?

The way they determine this is the tool accesses a page using a standard method (e.g. POST) and gets the response.  Then the same page is requested using a bogus verb. The same result comes back in the response, so it assumes that the verb tampering was successful.

Details of one example from the error report:

URL: http://[DOMAIN]:8080/osd.jsp

Risk: It might be possible to escalate user privileges and gain administrative permissions over the web application. It is possible to gather sensitive information about the web application such as usernames, passwords, machine name and/or sensitive file locations

Method manipulated from: GET to: BOGUS
Reasoning: The test result seems to indicate a vulnerability because the Test Response is
identical to the Original Response, indicating that the verb tampering was able to
bypass the site authentication

[Daniel Eads · Accepted solution]

Hey Thomas,

The particular example you showed (osd.jsp) is the Open Search Description file. Let's take a look at the contents:

<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/" xmlns:moz="http://www.mozilla.org/2006/browser/search/">
 <ShortName>Your Company JIRA</ShortName>
 <Description>Atlassian JIRA Search Provider</Description>
 <Image height="16" width="16" type="image/x-icon">http://yourjira/images/16jira.png</Image>
 <Image height="64" width="64" type="image/png">http://yourjira/images/64jira.png</Image>
 <Url type="text/html" template="http://yourjira/secure/QuickSearch.jspa?searchString={searchTerms}"/>
 <Query role="example" searchTerms="JIRA"/>
 <InputEncoding>UTF-8</InputEncoding>
 <moz:SearchForm>http://yourjira/secure/QuickSearch.jspa</moz:SearchForm>
</OpenSearchDescription>

This file contains all the necessary info to let your browser understand how to let you search Jira from the browser's search bar:

For this particular file, we actually want unauthenticated users to be able to access it so they have a good search experience. Many Jiras are public in the sense that they have some projects people can view issues on without having to log in. jira.atlassian.com is the prime example of this - anyone can search issues that we've set the projects to public visibility on.

I'm not concerned that other verbs return this file (and it's all the .xml file each time) as there is no private data in this file and it doesn't need to have permission checked.

It would be interesting to know if the other files the scan found were things like robots.txt (the file that helps search engines know what to index and ignore). If it's all this type of file, I'd try to just have the scan ignore those files or disregard that part of the scan. For this particular one, I'd say "false positive".

Cheers,
Daniel

[Thomas Douglas]

Hi Daniel. thanks for the very useful information! I listed the other files below. It's hard for me to tell (not knowing the code based nor Java/Tomcat environments very well) whether they should be secured or not. Some seem obvious that you would not want secured (login.jsp). For other ones it is not so obvious that they shouldn't be secured.  It's interesting that a couple in fact are in a folder called "secure" - not that we should necessarily draw any conclusions based on a folder name.

Thanks for any help!

http://[DOMAIN]/secure/JiraCreditsPage!default.jspa

http://[DOMAIN]/secure/AboutPage.jspa

http://[DOMAIN]/secure/Logout.jspa

http://[DOMAIN]/login.jsp

[Daniel Eads]

Hey Thomas,

I've seen Qualys WAS return the same 5 pages (the four you've just listed plus the osd file) in addition to the robots.txt file being public. After reviewing those pages (credits and about are static text, the login/logout pages need to be public) I felt safe having future scans ignore that result.

I've also had a chat with our security team and they've confirmed there's nothing to worry about on these pages in regards to verb tampering. We're writing up a knowledgebase article with this info! In the meantime, no worries listing those files as false positives.

Cheers,
Daniel | Atlassian Support

[Thomas Douglas]

Thanks very much!