Responsible disclosure

För Svenska Postkodlotteriet är våra kunder, och därmed även säkerheten för våra system, prioriterade. Om du tror dig inneha information om omständighet som kan påverka säkerheten i våra system tar vi tacksamt emot den. Lämna informationen via vårt Responsible Disclosure Report-system. Du finner en länk till systemet längst ner på denna sida.

Tänk på att:

  • Rapportera informationen skyndsamt för att förhindra att obehöriga utnyttjar informationen.
  • Rapportera på ett säkert sätt som hemlighåller innehållet i rapporten, för att minimera risken att andra får tillgång till informationen innan ett eventuellt problem är löst.
  • Delge tillräcklig information för att reproducera problemet så att vi har möjlighet att lösa det. Normalt räcker det att ange IP-adressen eller URL för berört system och en beskrivning av problemet. Komplexa sårbarheter kan dock kräva ytterligare information.

Det är inte tillåtet att:

  • dela informationen med andra innan problemet har blivit löst.
  • kopiera, modifiera eller radera data i våra system.
  • använda överbelastningsmetoder (DDOS, DOS), systematisk gissning av lösenord (s k brute force), social manipulation, skräppost eller applikationer från tredje part för att få tillgång till systemet.
  • missbruka information om det eventuella problemet. Missbrukas informationen kan vi behöva vidta legala åtgärder.

Vårt löfte till dig:

  • Vi återkommer till dig inom fem arbetsdagar med en utvärdering och förväntat datum för åtgärd. Vi kommer att hålla dig informerad om hur ärendet fortlöper.
  • Om du har följt ovan riktlinjer kommer vi inte att vidta legala åtgärder mot dig avseende din rapportering.
  • Du får vara anonym eller använda pseudonym när du rapporterar.
  • Om du väljer att uppge ditt namn kommer vi inte att vidarebefordra dina personuppgifter till tredje part om det inte är nödvändigt enligt lag.
  • Du har möjlighet att avböja publicering av ditt namn vid publicering av information avseende rapporterat problem.
  • Vi strävar efter att lösa alla problem så snart möjligt och vill vara avsändare vid eventuell kommunikation kring problemet.

Sårbar information:

Vi definierar sårbar information enligt följande: sårbarheter i web applikation såsom XSS, XXE, CSRF, SQLi, Local/ Remote File Inclusion, autentiseringsproblem, fjärrkörning av kod, behörighetsproblem, eskalering av privilegier. Dessa sårbarheter måste ha en påverkan på web applikationens säkerhet och innebära en ökad risk för våra kunder. För att du exempelvis ska namnges vid eventuell kommunikation kring problemet måste du vara den första person som på ett ansvarsfullt sätt uppmärksammar oss på sårbarheten.

Varje bidrag kommer att utvärderas från fall till fall. Nedan följer några problem som inte utgör en sårbarhet för säkerheten.

  • Rapport om gammal mjukvara
  • Avsaknad av ”best practice”
  • Använda komponenter med känd sårbarhet utan relevant POC attack
  • Automatiserade verktygsskanningsrapporter. Exempel: Web, SSL/ TLS-skanning, Nmap-scanningsresultat etc.
  • Self-XSS och XSS som endast påverkar föråldrade webbläsares UI och UX-buggar samt stavfel.
  • TLS/ SSL-relaterade problem
  • SPF, DMARC, DKIM konfigurationer
  • Sårbarheter på grund av föråldrade webbläsare eller plugins
  • Content Security Policies (CSP)
  • Sårbarheter i livscykelprodukter
  • Avsaknad av säker flagga på cookies
  • Uppräkning av användarnamn
  • Sårbarheter som bygger på förekomsten av plugins såsom Flash
  • Brister som påverkar användare av föråldrade webbläsare och plugins
  • Avsaknad av säkerhetsrubriker, såsom men inte begränsat till "content-type-options", "X-XSS-Protection"
  • Avsaknad av CAPTCHAs som säkerhetsskyddsmekanism
  • Problem som involverar en skadligt installerad applikation på enheten
  • Sårbarheter som kräver en ”jailbroken device”
  • Sårbarheter som kräver fysisk åtkomst till mobila enheter
  • Användning av ett känt och sårbart bibliotek utan bevis för exploaterbarhet
  • Click/Tap-jacking och UI-redressing attacker som innebär att du lurar användaren att klicka i ett UI användargränssnitt
  • Host header och banner grabbing problem
  • Denial of Service attacker och Distributed Denial of Service attacker
  • Rate limiting och brute force attack
  • Logga in/ logga ut/ CSRF med låg affärsrisk
  • Session fixation och session timeout
  • Formulär/ CSV-injektion

Övrig information:

  • Ekonomisk ersättning för information enligt ovan utgår inte.

Tack för ditt bidrag.

Rapportera ditt bidrag

Responsible disclosure

At the Swedish Postcode Lottery our customers, and hence the security of our systems, is top priority. If you believe you have discovered a vulnerability that may impact the security of our systems we are grateful for receiving information about it. Please submit your findings via our Responsible Disclosure Report-system. You will find the link below.

Please do the following:

  • Report the vulnerability as quickly as is reasonably possible, to minimise the risk of hostile actors finding it and taking advantage of it.
  • Report in a manner that safeguards the confidentiality of the report so that others do not gain access to the information.
  • Provide sufficient information to reproduce the problem, so we will be able to resolve it. Usually, the IP address or the URL of the affected system and a description of the vulnerability will be sufficient. However, complex vulnerabilities may require further explanation.

Please do not:

  • Reveal the vulnerability or problem to others until it is resolved.
  • Copy, modify or delete data in the system.
  • Use distributed denial of service or denial of service, brute force attacks, social engineering, spam or applications of third parties to gain access to the system.
  • Abuse the vulnerability. If this happens we may have to pursue legal action.

What we promise:

  • We will respond to your report within five business days with our evaluation of the report and an expected resolution date. We will keep you informed of the progress towards resolving the problem.
  • If you have followed the instructions above, we will not take any legal action against you concerning the report.
  • You may report under a pseudonym or anonymously.
  • If you chose to state your name, we will not pass on your personal details to third parties without your permission, unless it is necessary to comply with a legal obligation.
  • You may refuse publication of your name at any publication of information regarding reported issues.
  • We strive to resolve all problems as quickly as possible, and we would like to be the sender of any publication on the problem.

Qualifying vulnerabilities

We define qualified vulnerabilities as follow: Web application vulnerabilities such as XSS, XXE, CSRF, SQLi, Local or Remote File Inclusion, authentication issues, remote code execution, and authorization issues and privilege escalation. These qualified vulnerabilities must have an impact on the security of the web application and an increased risk for our customers. In order for us to i.a. be able to state your name in any publication, you must be the first researcher to responsibly disclose the vulnerability.

Each submission will be evaluated on a case-by-case basis. Below is a list of some of the issues which don’t qualify as security vulnerabilities:

  • Reports of old software versions
  • Missing best practices
  • Using components of known vulnerability without relevant POC of attack
  • Automated tool scan reports. Example: Web, SSL/TLS scan, Nmap scan results etc.
  • Self-XSS and XSS that affects only outdated browsers UI and UX bugs and spelling mistakes
  • TLS/SSL related issues
  • SPF, DMARC, DKIM configurations
  • Vulnerabilities due to out of date browsers or plugins
  • Content Security Policies (CSP)
  • Vulnerabilities in end of life products
  • Lack of secure flag on cookies
  • Username enumeration
  • Vulnerabilities relying on the existence of plugins such as Flash
  • Flaws affecting the users of out-of-date browsers and plugins
  • Security headers missing such as, but not limited to "content-type-options", "X-XSS-Protection"
  • CAPTCHAs missing as a Security protection mechanism
  • Issues that involve a malicious installed application on the device
  • Vulnerabilities requiring a jailbroken device
  • Vulnerabilities requiring a physical access to mobile devices
  • Use of a known vulnerable library without proof of exploitability
  • Click/Tap-jacking and UI-redressing attacks that involve tricking the user into tapping a UI element
  • Host header and banner grabbing issues
  • Denial of Service attacks and Distributed Denial of Service attacks
  • Rate limiting, brute force attack
  • Login/logout/low-business impact CSRF
  • Session fixation and session timeout
  • Formula/CSV Injection

Other information:

  • Financial compensation for your information in accordance with above, is not paid.

Thank you for your contribution.

Submit your findings