[CKAN-Security] CKAN security vulnerabilities

Sat Apr 9 06:35:31 UTC 2016

A client of ours has recently had some penetration testing conducted on a
couple of CKAN 2.4.1 applications we've been working on.  Here is the
summary of the issues reported by the security consultants that I think
relate to core CKAN, along with some of the suggestions to mitigate these
risks.  I haven't tested that these vulnerabilities exist in later versions
of CKAN or whether issues have already been logged.

The risk ratings were provided by the security consultants based on their
own calculation of the CVSSv2 score.

I'm happy to provide more info from the consultant's report if you wish but
I should probably check this with our client first.

I'm also happy to log these in the private security issue repo if you grant
me access.

What we don't know yet, is which issues we will have to resolve prior to
our launch date in 1-2 weeks. We're assuming the high rated issues and
potentially some medium issues. We're happy to implement fixes but tech
team direction to help with general solutions would be great.

Cheers
Mark

High

*Resource Proxy server-side request forgery* - the resource proxy can be
used to return results from within the server's local network, or other
networks it has access to. Protection can come from configurable protocol
and port restriction, and a configurable blacklist with appropriate
defaults (e.g., block localhost). A configurable whitelist may be useful in
some use cases, including ours. There is a Python library that wraps
requests, called Advocate, that is designed to prevent SSRF attacks.

*No restriction of uploaded files types* - allowing upload of HTML or SWF
with client-side script, malware, etc.  May be able to easily mitigate this
somewhat with file type check but adding malware/virus scanning would grant
greater protection.

Medium

*Cross-site-request forgery* - user tricked into browsing to a malicious
HTML page could be used to access restricted functionality in the site,
e.g., user privilege elevation

*JSONP Cross-Site Script Inclusion (XSSI)* - user tricked into visiting a
malicious HTML page could extract user's API key. Prevent user_list and
user_show from returning the API key.

*API accepts cookie authentication* - makes the API vulnerable to the CSRF
and XSS attacks.

*Weak Password and Account Lockout Policy*

*Third-Party JavaScript Library Inclusion*

Low

*Ineffective Session Termination* - as tested, cookies from terminated
sessions could be successfully re-used later. * Possibly our implementation
with ckanext-saml2

*Cacheable HTTPS Responses*

*Concurrent Logins Allowed* - allows multiple logins for a single user,
including from multiple IP addresses * Possibly our implementation

Info

*Insufficient defence against clickjacking*

*Application Reverted to HTTP upon Successful Authentication* * Possibly
local implementation

*Self-Registration Allows Registration of Reserved Usernames* - "register"
and "reset" were not blocked from users registering these usernames,
suggestion is also to block authoritative sounding usernames such as
"admin" and "administrator" which could facilitate social engineering
techniques.

*API Exposes Hashed Email Address*

*MARK GREGSON * |  *DEVELOPMENT TEAM LEAD*
Link Digital

www.linkdigital.com.au
p: *02 6111 2907* | f: 02 6248 5582
GPO Box 199 Canberra ACT 2601
5/32 Lonsdale Street Braddon ACT 2612
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.okfn.org/mailman/private/security/attachments/20160409/b3b1e216/attachment.html>