Brand Promise 

Allianz is a multinational financial services company (headquartered in Munich, Germany). 

No system is completely safe! For Allianz having secure systems and applications is essential to protect its core businesses (insurance and asset management). Hence, we believe that working with skilled security researchers is crucial in identifying & resolving vulnerabilities. 

By submitting reports or otherwise participating in this program, researchers agree to follow the program rules of this program policy. Allianz reserves the right to discontinue the program at any time without notice in its sole discretion. 

Allianz thanks researchers for submitting findings to Allianz VDP and the contribution to improve the security posture of Allianz’ IT systems and applications. 

Researchers might perform actions that are punishable by German law. If researchers act with integrity and follow VDP rules, Allianz will not report researchers’ offense to authorities.  

While researching, do not cause damage and disrupt Allianz services. To refrain and comply with the terms, Researchers and their findings must meet the following eligibility requirements: 

• Do not test assets of entities, which are not fully or majority-owned by AZ Group  
  
• Do not test third party Applications / Websites / Services / API that link to Allianz 
• Do not perform any physical attempts against Allianz property or data centers  
• Do not run automated scanners / tools and perform tests leading to operational failure 
• Do not execute or attempt to execute any “Denial of Service” attack 
• Do not research resulting in sending unsolicited or unauthorized junk mail, spam or other forms of unsolicited messages 
• Do not use Social engineering (e.g., phishing, vishing, smishing) of Allianz staff or contractors 
• Submit one finding per report  
• Multiple vulnerabilities caused by one underlying vulnerability will be considered duplicates. 
• When duplicates occur, Allianz will only review the first reported finding 
• Researchers are expected to interact only with their own accounts 
• Allianz analysis is always based on worst case exploitation of the vulnerability 
• Use all reasonable efforts to avoid privacy violations, destruction of data, and interruption or degradation of Allianz service 
• Promptly notify Allianz upon discovery of a vulnerability (no later than 24 hours after discovery and exclusively through HackerOne platform) 
• If researchers inadvertently access customer, employee, or business-related information during their testing, they must immediately notify Allianz and the information must not be used, disclosed, stored, or recorded in any way. Inadvertent access of the data must be declared within the researcher's submission 

Researchers are expected to only interact with their own accounts.

Access management: 

• Public access where no accounts and credentials are needed 
• Public access where users ca sign up for an account through self-registration. Note that in case accounts have been created for access, please update us so that the accounts can be deleted (post testing). 

• DO NOT discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from Allianz.
• Follow HackerOne's disclosure guidelines

When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. 

• Lack of HTTP Strict Transport Security (HSTS), Cross-site scripting (XSS)
• All vulnerabilities in Flash files are out of scope 
• Reports from automated tools or scans or outdated browsers
• Reports about insecure SSL / TLS configuration, Tab nabbing
• Weak Certificate Hash Algorithm 
• Findings without clearly identified security impact (such as clickjacking on a static website) or speculative theoretical exploitability - for example using UXSS to steal the auth cookies, identifying Apache Tomcat 8.0.43 but not being able to perform any attack 
• Missing security best practices and controls (rate-limiting / throttling, lack of Cross-Site Request Forgery (CSRF) protection, lack of security headers, missing flags on cookies, descriptive errors, server/ technology disclosure - without clear and working exploit) 
• Lack of crossdomain.xml, p3p.xml, robots.txt or any other policy files and / or wildcard presence / misconfigurations in these 
• Publicly accessible login panels, Reflective File Download 
• Clickjacking *CSS Injection attacks (unless it enables researchers to read anti-CSRF tokens or other sensitive information) 
• Host Header Injection (unless it gives researchers access to interim proxies or can be used to change the application flow and impact security) 
• Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin: * or accepting of custom Origin header that do not specifically show a valid attack scenario 
• PRSSI - Path-relative stylesheet import vulnerabilities (without a impactful exploitation scenario - for example stealing CSRF-tokens) 
• Our policies on presence / absence of SPF / DKIM / DMARC records 
• Lack of DNS, CAA, and DNS-related configuration 
• Any physical / wireless attempt against property or data centers 

Vulnerabilities which allow execution of code on the application server or shell command on the server itself should be run in accordance with this policy. 

Exploitation of possible RCE vectors is only allowed to show the basic impact of the vulnerability. For example: issue ipconfig + whoami on Windows or ifconfig + whoami/id on Unix. 

Vulnerabilities which allow injection of attacker-controlled parts of the SQL query should be run in accordance with this policy. 

Exploitation of SQLi is only allowed to show the basic impact of the vulnerability, e.g., by issuing SELECT queries such as @version 

If file uploads are possible in the application through any means (e.g., PUT HTTP Method, FileUpload functionality, etc.) please stick to the following rules. 

The following actions are prohibited: 

• Altering/ Modifying/ Deleting/ Replacing any files on the system. (e.g., defacement) o Exception: if it is explicitly given in the target scope to test for defacement possibilities replace one symbol/ image on the site with a different colored ones for proof and replace it back afterwards 
• Uploading files to the account of a user which is not owned by researchers and researchers who are not authorized (does not apply to system users or web users like www-data e.g.) 
• Uploading files which deliberately introduce additional exploitation vectors (e.g. html code with cross-site scripting code on it etc.) 
• Uploading files which can cause Denial of Service (e.g., over-sized files or unlimited number of files resulting in running out of Disk Quota)  o Allowed actions when conducting File-upload attempts: 
  - Chained exploitation vectors allowing researchers to jump out from the upload folder using e.g., path traversal or path manipulation that do not violate prohibited actions mentioned in File-Upload Policy. 
  - Upload of a file (any extension) with no content, simple string, integer, or a special character 
• Do not post, transmit, upload, link to, send or store any malicious software 

Any activities conducted in a manner consistent with this policy will be considered authorized conduct and Allianz will not initiate legal action against researchers. If legal action is initiated by a third-party against researchers in connection with activities conducted under this policy, Allianz will take steps to make it known that researchers’ actions were conducted in compliance with this policy. 

Please submit a report to Allianz before engaging in any conduct that may be inconsistent with or unaddressed within this Policy. 

Allianz reserves the right to discontinue the program at any time without notice in its sole discretion. 

Allianz genuinely thanks researchers for helping keep Allianz’s users, systems and applications  safe! 

Please submit you findings here – Submission Form