earthgecko / skyline

Hello,

I noticed a Cross-Site Scripting (XSS) security vulnerability in skyline/webapp/webapp.py.

Line 1524 in 2faefc8

return resp, 404

The vulnerability can be triggered by accessing "/ionosphere?...&fp_matches=true&fp_id=<script>alert(evil_code)</script>. Here the value of the HTTP fp_id parameter is injected into resulting html page without any prior sanitization. This allows attackers to make users execute arbitrary code, which is a serious security risk.

If your application is meant to be deployed in multi-user environments, where some of the user are not trusted, i would suggest to fix this issue. A trivial fix would be to sanitize the resulting html page:

return flask.escape(resp), 404

I found the bug while testing DeepCode’s AI Code Review. The tool can help you automate the process of finding such (and many other types of) bugs. You can sign-up your repo (free for Open Source) to receive notifications whenever new bugs are detected. You can give it a try here.

Any feedback is more than welcome at chibo@deepcode.ai.

Cheers, Victor.

Hi @tch1bo

Thanks for the reports. I know there are some holes, thanks for pointing them
out and suggesting flask.escape(resp). That suggestion was much
appreciated!

And just to be clear on the points for anyone happening to stumble onto this.
The XSS and the SQL injections vulnerabilities (#86) are known and stated in the
documentation - https://earthgecko-skyline.readthedocs.io/en/latest/webapp.html?highlight=injection#production-infrastructure

These vulnerabilities are somewhat offset by the implementation of a number of
migitations such as:

The implementation of basic http auth and a SSL terminated frontend
Forcing @requires_auth on all the webapp.py endpoints
Testing the validilty each parameter in the requests

These are not excuses, they are mitigations for known lacks of knowledge in
certain aspects.

In your example, webapp.py will respond with Bad request 400 as fp_id as a
Python type is not instanceof int.

Due to this lack of knowledge on a number of fronts in terms of sorting out XSS
and SQL injection, all request parameter values are tested and further to this
the user of Skyline is somewhat now forced into setting it up with multiple
layers of defence in terms of it's actually deployment. But you cannot always
rely on users to read the documentation and do it properly, so the default
setup makes it hard to configure it open, by default it is configured hard.

Although it would be much better to fix it as well, I do agree :)

I shall draft a release to address the XSS and mull over the SQL #86 as well.

Thanks for the report. I guess we are a ways off deepcode.ai being able to
analyse code, configs and docs in a multivariate manner good enough to interpret
stuff that has an average cyclonic complexity score of about F AND make
sense of it all :) But I do like it :)

Cross-Site Scripting Security Vulnerability