I'm getting a report from our security people that a search like this:
/omeka/items/browse?submit_search=oiewbb
where you have a nonsense string as the search string indicates that it
"may be vulnerable to CGI injectable parameter", which in turn implies "The affected parameters are candidates for extended injection tests like cross-site scripting attacks"
This risk of this is quite low, but I'm wondering if anyone else has encountered this and how it might be addressed.
If I've understood the behavior correctly, when I search for nonsense, I get back a full list of items in the Omeka instance when I would expect to get some kind of "404 - not found" or other "no results" page.
Is this just a configuration parameter I have set wrong? Or is it a designed behavior that may need to be addressed in some other fashion?
Thanks for your help.
Bobb Menk
MIT Lincoln Laboratory Library
submit_search is just the search button's input name, it doesn't affect the search results in any way.
search is the simple search GET parameter. If you put a nonsense string in there, you get back no results.
It's possible there's a genuine XSS vulnerability on the items/browse page, but it would be news to us. We generally don't include the GET parameters in the results page, and where we do, we're careful to escape HTML characters or completely replace the input.
What I'm seeing when I do a normal search by typing nonsense in the search box is that I go back to the top level with a "0 hits" message.
That search string looks like this:
/omeka/items/browse?search=dfxcv&submit_search=Search
However, if I formulate the search string like this (which the Nessus security scan did):
/omeka/items/browse?&submit_search=djfvndfj
I get back the complete list of items in Omeka. Which doesn't seem like it should happen. I don't know if it shows any potential for harm or not, but it's what my security people are asking me.
So to clarify, it's this part of the search string:
browse?search=dfxcv&submit_search
vs. this:
browse?&submit_search=djfvndfj
Thanks.
Bobb Menk
Sure, I think I understand what you're saying. I don't think this is a problem in any way.
That submit_search GET parameter that the security scan is putting junk into simply affects nothing. That's why you see all the items. It's the equivalent of putting ?irrelevant=whatever at the end of any given URL.
Basically, I'm not sure why the scanner is flagging this as an issue.
Okay, I think I see what's happening here.
That low-severity "hit" from the security scanner just tests to see if an ordinary string from the input can show up in the page. It does this as a first step, to mark areas that need to be checked for actual injection vulnerabilities, like allowing HTML/JavaScript to be injected through the URL.
I think in this case, there's no action that needs to be taken as a result of that scan result. Omeka already makes sure to properly escape data from the URL when it does get included in the page.
Thanks for the explanation. I'll pass it along to the powers that be.
Bobb