The LME greatly appreciates and supports working with the well-intentioned, ethical, security research community. We are proud of this collaboration and are committed to thoroughly investigating and resolving security issues in our platform and services - to ensure a safer environment for all. Please do read the disclosure policy in full before reporting vulnerabilities.
This document defines the process in which the LME can work with the wider security research community to improve the LME’s online security.
Scope
Vulnerabilities in the London Metal Exchange products and service are only valid providing:
- They have not been reported previously or have not already been discovered by our internal procedures.
- There is the potential for a real impact to the LME, its users or customers should the vulnerability be exploited by a malicious actor. The existence of a potential vulnerability does not necessarily demonstrate that a potential impact exists, theoretical impacts are not considered within scope.
- It exists within a domain that has a security.txt file in it’s root. Subdomains are considered in scope provided that their parent domain is in scope unless otherwise stated.
- Security.txt exists on lme.com, however, datalicensing.lme.com, securemail.lme.com and surveys.lme.com are all out of scope of this scheme.
The following security issues are not within scope of this policy (please do not report these):
- Any vulnerabilities within datalicensing.lme.com, securemail.lme.com, surveys.lme.com
- Volumetric/Denial of Service vulnerabilities.
- Self XSS (i.e. where a user would need to be tricked into pasting code into their web browser).
- Error messages, including details error messages, e.g. stack traces.
- HTTP response codes outside of the 200 range, e.g. a 404 response.
- The HTTP OPTIONS method enabled.
- Missing HTTP headers, e.g. Content-Security-Policy, X-Frame-Options, etc.
- All HTTPS issues, e.g. mixed content.
- ALL SSL/TLS issues, e.g. SSLv3 enabled, BEAST, certificate issues, etc.
- Lack of security related flags on non-sensitive cookies, e.g. HttpOnly, Secure, etc.
- Banner disclosure, e.g. a HTTP server header, even if it has the version number.
- Areas for infrastructure configuration improvement, e.g. no or poorly configured DKIM.
- Existence of known public files or directories, e.g. robots.txt or /wp-admin.
- Clickjacking.
- CSRF on unauthenticated functionality, e.g. contact form, logout, etc.
- Unrestricted volume of form submissions, e.g. contact form.
- The simple presence of credential autocomplete or ‘remember me’ type functionality.
- Reverse tabnabbing.
- No CAPTCHA or a weak CAPTCHA.
- Lack of security ‘speed bumps’ or warning messages when leaving the application.
- Username enumeration, including emails as usernames, unless; i) usernames are retrievable en masse, and; ii) retrievable without the user of username fuzzing, and, iii) with no prior knowledge of the usernames, and; iv) from a no privilege or standard privilege account.
- Admin functionality giving access to sensitive data or functionality that could reasonably be expected to apply to an admin level of trust.
Bug bounty
We currently do not offer a paid bug bounty programme, however, we may after consideration offer a token of appreciation to security researchers who have taken time and effort to investigate and report security vulnerabilities to us adhering to this policy. This is entirely discretionary and usually based on the severity and potential impact.
Reporting a vulnerability
If you have discovered a vulnerability that you believe is in scope (see Scope section above), please email security@lme.com including the following in your submission:
- The website or page where the vulnerability exists
- A brief description of the type of vulnerability, i.e. “XSS Vulnerability”
Ensuring to use our public PGP key (below) for encryption: Please also provide a benign, non-destructive, proof of exploit where possible. This helps to ensure your report can be triaged quickly and accurately. It also reduces the likelihood of duplicate reports and/or malicious exploitation of some vulnerabilities, for example subdomain takeovers.
PGP Key:
-----BEGIN PGP PUBLIC KEY BLOCK-----
mDMEZe7hexYJKwYBBAHaRw8BAQdANMGHFgAdsT8snJEO0Jkz3KzxOhE1lI7SS56Y
if4mfCu0HURpc2Nsb3N1cmUgPFNlY3VyaXR5QGxtZS5jb20+iJkEExYKAEEWIQTb
ftrO5903oneCHhd5FMVaTn7cgAUCZe7hewIbAwUJBaOrRQULCQgHAgIiAgYVCgkI
CwIEFgIDAQIeBwIXgAAKCRB5FMVaTn7cgEdPAP9Y02ko0ga2DRF2V2p1mKNR7NQA
Yp+9iDkiowfEosB2YQEAlsQeDvtcME2iUAsTTpkZNwgKn2hKpgYCDyGuWRTeyAi4
OARl7uF7EgorBgEEAZdVAQUBAQdAhFTccI7K/h914pp0ITWjgmqHobRydrpNM2GE
SPyogz8DAQgHiH4EGBYKACYWIQTbftrO5903oneCHhd5FMVaTn7cgAUCZe7hewIb
DAUJBaOrRQAKCRB5FMVaTn7cgAfnAP9rBVOLQCRgIGNMTiBxLsB1teh4d3agtaAP
hZpKkMisPwEAuB//i5gqQnz1JR26t43DAm8wn2LNTBvP+TbJQzePpgI=
=2j2g
-----END PGP PUBLIC KEY BLOCK-----
What to expect
After your vulnerability report has been submit, we will send an acknowledgement reply to you, usually within 48 working hours of receiving your report.
Your report will then be triaged by the LME Security team whom will respond as soon as possible to confirm if further information is required, the vulnerability is in or out of scope, or if it is a duplicate report that is currently being worked on. If your report is confirmed to be in scope of this policy, remediation work will be identified and assigned to the appropriate London Metal Exchange teams and/or supplier(s).
Priority fixes or mitigations will be assessed based on the impact and feasibility of exploit. Reports may take some time to address – you are welcome to request a status update on your report, however, please do avoid doing so more than once every 14 days to allow our teams to focus on the report.
Once the reported vulnerability has been resolved, the team will notify you and ask you to confirm the that the solution covers the vulnerability adequately.
Guidance
Security researchers must not:
- Access unnecessary amounts of data. For example, 2 or 3 records is enough to demonstrate most vulnerabilities, such as enumeration or direct object reference vulnerability.
- Violate the privacy of the London Metal Exchange users, staff, contractors, service or systems. For example, by sharing, redistributing and/or not properly securing data retrieved from our systems or services.
- Communicating any vulnerabilities or associated details via methods not described in this policy or with anyone other than your LME Security representative.
- Modify data in the London Metal Exchange systems/services that is not your own.
- Disrupt the London Metal Exchange services or systems
- Disclose vulnerabilities in the London Metal Exchange systems or services to 3rd parties or the public, prior to the London Metal Exchange confirming that the vulnerabilities have been fixed or mitigated.
We ask that all data retrieved during your research is securely deleted as soon as it is no longer required and at most 1 month after the vulnerability is resolved, whichever occurs first.
Legalities
This policy is designed to be compatible with common vulnerability disclosure among well-intentioned security researchers. It does not give permission to act in any manner that is inconsistent with the law or cause the London Metal Exchange to be in breach of it’s legal obligations, included but not limited to:
- The Computer Misuse Act (1990)
- The General Data Protection Regulation 2016/679 (GDPR) and the Data Protection Act 2018
- The Copyright, Designs and Patents Act (1988)
The London Metal Exchange affirms that it will not seek prosecution of any security researcher reporting a security vulnerability that has acted in good-faith and adhered to this disclosure policy.