I'm not sure I class this as a verifiable security issue, but Nessus is reporting it as such, and I can see how it could become one.
Basically, the JSON gem isn't encoding < and > as it should be, and they're output directly in the call to Search.init.
Nesus returns the following:
The request string used to detect this flaw was :
/?<script>cross_site_scripting.nasl</script>
The output was :
HTTP/1.1 200 ...
Cache-Control: private, max-age=0
Content-Type: text/html
Content-length: 13514
Search.init({ 'grep': ["/var/log/apache2/all_vhosts.log","/var/log [...]
'tail': ["/var/log/apache2/all_vhosts.log","/var/log/bigcommerce_s [...]
{"<script>cross_site_scripting.nasl</script>":""} );
As I mentioned, I'm not sure with the limited usage in Clarity if this will cause any issues, and I know it's more of a fix the JSON gem author should put in, but right now I just need our Nessus scanner to shut the hell up for PCI compliance :)
I'm not sure I class this as a verifiable security issue, but Nessus is reporting it as such, and I can see how it could become one.
Basically, the JSON gem isn't encoding < and > as it should be, and they're output directly in the call to Search.init.
Nesus returns the following:
Rails had a similar issue a long time ago in their own JSON encoding: http://webcache.googleusercontent.com/search?q=cache:N3iGwpwoMg0J:dev.rubyonrails.org/ticket/8371+to_json+xss&cd=1&hl=en&ct=clnk&gl=au
As I mentioned, I'm not sure with the limited usage in Clarity if this will cause any issues, and I know it's more of a fix the JSON gem author should put in, but right now I just need our Nessus scanner to shut the hell up for PCI compliance :)