At the Awoostria, we consider the security of our systems a top priority. But no matter how much effort we put into system security, there can still be vulnerabilities present. 

If you discover a vulnerability, we would like to know about it so that we can take steps to address it as quickly as possible. We would like to ask you to help us better protect our systems and attendees.

Please do the following: 

• E-mail your findings to [email protected], or contact our IT department at https://awoostria.at/contact?department=it-department if the vulnerability doesn't affect our web server or mail server. If neither of those options seem like a good choice, message [email protected] or contact me on Telegram at @DotDoggo.

• Do not take advantage of the vulnerability or problem you have discovered, for example by downloading more data than necessary to demonstrate the vulnerability or deleting or modifying other people's data, 

• Do not reveal the problem to others until it has been resolved, 

• Do not use attacks on physical security, social engineering, distributed denial of service, spam or applications of third parties, and 

• Do provide sufficient information to reproduce the problem, so we will be able to resolve it as quickly as possible. Usually, the IP address or the URL of the affected system and a description of the vulnerability will be sufficient, but complex vulnerabilities may require further explanation. 

What we promise: 

• We will respond to your report within 3 business days with our evaluation of the report and an expected resolution date, 

• If you have followed the instructions above, we will not take any legal action against you in regard to the report, 

• We will handle your report with strict confidentiality, and not pass on your personal details to third parties without your permission, 

• We will keep you informed of the progress towards resolving the problem, 

• In the public information concerning the problem reported, we will give your name as the discoverer of the problem (unless you desire otherwise)

Exclusions:

The following test types are excluded from the scope:

• Findings derived primarily from social engineering (e.g. phishing, vishing).

• Vulnerability reports with video only PoCs.

• Reports that state that software is out of date or vulnerable without a proof of concept.

• Highly speculative reports about theoretical damage. Be concrete.

• Vulnerabilities as reported by automated tools without additional analysis as to how they’re an issue.

• Issues in third-party services should be reported to the respective team.

The following issue types are excluded from scope:

• Network-level Denial of Service (DoS/DDoS) vulnerabilities.

• Low severity issues that can be detected with tools such as Hardenize and Security Headers.

• Content injection issues.

• Cross-site Request Forgery (CSRF) with minimal security implications (Logout CSRF, etc.).

  • In order for CSRF to be a valid issue it must affect some important action such as deleting one's account.

• Missing cookie flags.

• UI and UX bugs (including spelling mistakes).

• 401 injection.

• Host header issues without an accompanying proof-of-concept demonstrating vulnerability.

• Open ports without an accompanying proof-of-concept demonstrating vulnerability.

• Banner grabbing issues (figuring out what web servers we use, etc.).

• Missing X-Frame-Options header (Clickjacking).

• Cross-site tracing.

  • In order for Cross-Site Tracing (XST) to really be a significant issue you would need to find an endpoint vulnerable to Cross-site Scripting (XSS).

• CSP uses unsafe-inline

  • The fact that a CSP includes unsafe-inline is not an issue in itself. In order for you to demonstrate the actual impact of this value, I highly recommend to look for an XSS vulnerability. Try to trigger alert(document.domain).

• Open redirect using Host header

Proof of concepts, and when to report them

• XSS

  • For XSS, a simple alert(document.domain) should suffice.

• RCE

  • Please only execute harmless code. Simply printing something or evaluating an expression should be enough to demonstrate the issue.

• SQLi

  • Report it as soon as you have a SQL error that indicates SQL injection, or you are able to disclose the SQL server's version number.

• Unvalidated redirect

  • Set the redirect endpoint to http://example.com.

• CSRF

  • Either attach a file to demonstrate the issue or paste the code in a code block in your report.

• SSRF

  • Do not go playing around on any internal networks. If you feel the necessity to retrieve an internal file, please only request the internal security.txt file.

• LFI

  • The same applies here — please do not go against the guidelines listed in this article. There should be a security.txt file located in the root directory. Being able to retrieve that file should be enough to demonstrate the issue.

 
We strive to resolve all problems as quickly as possible, and we would like to play an active role in the ultimate publication of the problem after it is resolved.