Full risk assessment

[Andreass2]

Architecture, Design and Threat Modeling

Beta Give feedback

1. V1.1.3: Verify that all user stories and features contain functional security constraints, such as "As a user, I should be able to view and edit my profile. I should not be able to view or edit anyone else's profile"
2. V1.1.4: Verify that major data flows as well as usage of other components (Altinn products and third party products/services) are documented and justified.
3. V1.1.5: Verify definition and security analysis of the application's high-level architecture and all connected remote services.
4. V1.2.2: Verify that communications between application components, including APIs, middleware and data layers, are authenticated. Components should have the least necessary privileges needed.
5. V1.5.2: Ensure that adequate integrity controls (in addition to encryption) are enforced to prevent deserialization attacks such as object injection.
6. V1.5.3: Verify that input validation is enforced on a trusted service layer.
7. V1.6.2: Verify that Azure Key Vault is used to protect key material and other secrets.
8. V1.6.4: Verify that the architecture treats client-side secrets--such as symmetric keys, passwords, or API tokens--as insecure and never uses them to protect or access sensitive data.
9. V1.9.1: Verify the application encrypts communications between components, particularly when these components are in different containers, systems, sites, or cloud providers.
10. V1.9.2: Verify that application components verify the authenticity of each side in a communication link to prevent person-in-the-middle attacks. For example, application components should validate TLS certificates and chains.
11. V1.11.1: Verify that application components are documented and that the documentation describes the business or security functions they provide.
12. V1.11.2: Verify that state is not shared across sessions. Consider integrity checks for all high-value transactions to avoid potential race conditions.
13. V1.12.2: Verify that user-uploaded files - if required to be displayed or downloaded from the application - are served by either octet stream downloads, or from an unrelated domain, such as a cloud file storage bucket. Implement a suitable Content Security Policy (CSP) to reduce the risk from XSS vectors or other attacks from the uploaded file. #484
    kind/user-story +1
    
14. V1.14.6: Verify the application does not use unsupported, insecure, or deprecated client-side technologies such as NSAPI plugins, Flash, Shockwave, ActiveX, Silverlight, NACL, or client-side Java applets.

Authentication

Beta Give feedback

1. V2.10.4: Verify that passwords, integrations with databases and third-party systems, seeds and internal secrets, and API keys are stored in Azure Key Vault and not included in the source code or stored within source code repositories.

Access Control

Beta Give feedback

1. V4.1.1: Verify that the application enforces access control rules on a trusted service layer, especially if client-side access control is present and could be bypassed.
2. V4.1.2: Verify that Altinn PDP is used for all authorization decisions, to prevent manipulation of user and data attributes and policy information used by access controls.
3. V4.1.3: Verify that the principle of least privilege exists - users should only be able to access functions, data files, URLs, controllers, services, and other resources, for which they possess specific authorization. This implies protection against spoofing and elevation of privilege.
4. V4.1.5: Use Altinn's policy enforcement points (PEP) to enforce authorization and fail securely when an exception occurs.
5. V4.2.1: Verify that sensitive data and APIs are protected against Insecure Direct Object Reference (IDOR) attacks targeting creation, reading, updating and deletion of records, such as creating or updating someone else's record, viewing everyone's records, or deleting all records.
6. V4.3.1: Verify administrative interfaces use appropriate multi-factor authentication to prevent unauthorized use.
7. V4.3.2: Verify that directory browsing is disabled unless deliberately desired. Additionally, applications should not allow discovery or disclosure of file or directory metadata, such as Thumbs.db, .DS_Store, .git or .svn folders.
8. V4.3.3: Verify the application has additional authorization (such as step up or adaptive authentication) for lower value systems, and / or segregation of duties for high value applications to enforce anti-fraud controls as per the risk of application and past fraud.

Validation, Sanitization and Encoding

Beta Give feedback

1. V5.1.1: Verify that the application has defenses against HTTP parameter pollution attacks, particularly if the application framework makes no distinction about the source of request parameters (GET, POST, cookies, headers, or environment variables).
2. V5.1.2: Verify that frameworks protect against mass parameter assignment attacks, or that the application has countermeasures to protect against unsafe parameter assignment, such as marking fields private or similar.
3. V5.1.3: Verify that all input (HTML form fields, REST requests, URL parameters, HTTP headers, cookies, batch files, RSS feeds, etc) is validated using positive validation (allow lists).
4. V5.1.4: Verify that structured data is strongly typed and validated against a defined schema including allowed characters, length and pattern (e.g. credit card numbers, e-mail addresses, telephone numbers, or validating that two related fields are reasonable, such as checking that suburb and zip/postcode match).
5. V5.1.5: Verify that URL redirects and forwards only allow destinations which appear on an allow list, or show a warning when redirecting to potentially untrusted content.
6. V5.2.1: Verify that all untrusted HTML input from WYSIWYG editors or similar is properly sanitized with an HTML sanitizer library or framework feature.
7. V5.2.2: Verify that unstructured data is sanitized to enforce safety measures such as allowed characters and length.
8. V5.2.3: Verify that the application sanitizes user input before passing to mail systems to protect against SMTP or IMAP injection.
9. V5.2.4: Verify that the application avoids the use of eval() or other dynamic code execution features. Where there is no alternative, any user input being included must be sanitized or sandboxed before being executed.
10. V5.2.5: Verify that the application protects against template injection attacks by ensuring that any user input being included is sanitized or sandboxed.
11. V5.2.6: Verify that the application protects against SSRF attacks, by validating or sanitizing untrusted data or HTTP file metadata, such as filenames and URL input fields, and uses allow lists of protocols, domains, paths and ports.
12. V5.2.7: Verify that the application sanitizes, disables, or sandboxes user-supplied Scalable Vector Graphics (SVG) scriptable content, especially as they relate to XSS resulting from inline scripts, and foreignObject.
13. V5.2.8: Verify that the application sanitizes, disables, or sandboxes user-supplied scriptable or expression template language content, such as Markdown, CSS or XSL stylesheets, BBCode, or similar.
14. V5.3.1: Verify that output encoding is relevant for the interpreter and context required. For example, use encoders specifically for HTML values, HTML attributes, JavaScript, URL parameters, HTTP headers, SMTP, and others as the context requires, especially from untrusted inputs (e.g. names with Unicode or apostrophes, such as �� or O'Hara).
15. V5.3.3: Verify that context-aware, preferably automated - or at worst, manual - output escaping protects against reflected, stored, and DOM based XSS.
16. V5.3.4: Verify that stored procedures are used for all database queries.
17. V5.3.6: Verify that the application protects against JSON injection attacks, JSON eval attacks, and JavaScript expression evaluation.
18. V5.3.7: Verify that the application protects against LDAP injection vulnerabilities, or that specific security controls to prevent LDAP injection have been implemented.
19. V5.3.8: Verify that the application protects against OS command injection and that operating system calls use parameterized OS queries or use contextual command line output encoding.
20. V5.3.9: Verify that the application protects against Local File Inclusion (LFI) or Remote File Inclusion (RFI) attacks.
21. V5.3.10: Verify that the application protects against XPath injection or XML injection attacks.
22. V5.4.2: Verify that format strings do not take potentially hostile input, and are constant.
23. V5.5.1: Verify that serialized objects use integrity checks or are encrypted to prevent hostile object creation or data tampering.
24. V5.5.2: Verify that the application correctly restricts XML parsers to only use the most restrictive configuration possible and to ensure that unsafe features such as resolving external entities are disabled to prevent XML eXternal Entity (XXE) attacks.
25. V5.5.3: Verify that deserialization of untrusted data is avoided or is protected in both custom code and third-party libraries (such as JSON, XML and YAML parsers).
26. V5.5.4: Verify that when parsing JSON in browsers or JavaScript-based backends, JSON.parse is used to parse the JSON document. Do not use eval() to parse JSON.

Stored Cryptography

Beta Give feedback

1. V6.2.2: Verify that industry proven or government approved cryptographic algorithms, modes, and libraries are used, instead of custom coded cryptography.
2. V6.2.3: Verify that encryption initialization vector, cipher configuration, and block modes are configured securely using the latest advice.
3. V6.2.4: Verify that random number, encryption or hashing algorithms, key lengths, rounds, ciphers or modes, can be reconfigured, upgraded, or swapped at any time, to protect against cryptographic breaks.
4. V6.2.5: Verify that known insecure block modes (i.e. ECB, etc.), padding modes (i.e. PKCS#1 v1.5, etc.), ciphers with small block sizes (i.e. Triple-DES, Blowfish, etc.), and weak hashing algorithms (i.e. MD5, SHA1, etc.) are not used unless required for backwards compatibility.
5. V6.2.6: Verify that nonces, initialization vectors, and other single use numbers must not be used more than once with a given encryption key. The method of generation must be appropriate for the algorithm being used.
6. V6.3.1: Verify that all random numbers, random file names, random GUIDs, and random strings are generated using the cryptographic module's approved cryptographically secure random number generator when these random values are intended to be not guessable by an attacker.
7. V6.3.2: Verify that random GUIDs are created using the GUID v4 algorithm, and a Cryptographically-secure Pseudo-random Number Generator (CSPRNG). GUIDs created using other pseudo-random number generators may be predictable.
8. V6.4.1: Verify that Azure Key Vault is used to securely create, store, control access to and destroy secrets.
9. V6.4.2: Verify that key material is not exposed to the application but instead uses an isolated security module like a vault for cryptographic operations.

Error Handling and Logging

Beta Give feedback

1. V7.1.1: Verify that the application does not log credentials or payment details. Session tokens should only be stored in logs in an irreversible, hashed form.
2. V7.1.2: Verify that the application does not log other sensitive data as defined in Personopplysningsloven and Digdir's policies. In general, logging of personal identifiable information (PII) to technical logs should be avoided if possible.
3. V7.1.3: Verify that the application logs security relevant events including successful and failed authentication events, access control failures, deserialization failures and input validation failures.
4. V7.1.4: Verify that each log event includes necessary information that would allow for a detailed investigation of the timeline when an event happens.
5. V7.3.1: Verify that all logging components appropriately encode data to prevent log injection.
6. V7.4.2: Verify that exception handling (or a functional equivalent) is used across the codebase to account for expected and unexpected error conditions.
7. V7.4.3: Verify that a "last resort" error handler is defined which will catch all unhandled exceptions. #490

Data Protection

Beta Give feedback

1. V8.1.3: Verify the application minimizes the number of parameters in a request, such as hidden fields, Ajax variables, cookies and header values.
2. V8.2.1: Verify the application sets sufficient anti-caching headers so that sensitive data is not cached in modern browsers. #485
   kind/user-story product/formidling product/meldingstjenesten +3
   
3. V8.2.2: Verify that data stored in browser storage (such as localStorage, sessionStorage, IndexedDB, or cookies) does not contain sensitive data.
4. V8.3.1: Verify that sensitive data is sent to the server in the HTTP message body or headers, and that query string parameters from any HTTP verb do not contain sensitive data.

Communication

Beta Give feedback

1. V9.2.3: Verify that all connections to external systems are authenticated - e.g. by verfifying the external system's TLS certificate (including signature chain and revocation status).

Malicious Code

Beta Give feedback

1. V10.2.1: Verify that the application source code and third party libraries do not contain unauthorized phone home or data collection capabilities.
2. V10.2.2: Verify that the application does not ask for unnecessary or excessive permissions to privacy related features or sensors, such as contacts, cameras, microphones, or location.
3. V10.3.1: Verify that if the application has a client or server auto-update feature, updates should be obtained over secure channels and digitally signed. The update code must validate the digital signature of the update before installing or executing the update.
4. V10.3.2: Verify that the application employs integrity protections, such as code signing or subresource integrity. The application must not load or execute code from untrusted sources, such as loading includes, modules, plugins, code, or libraries from untrusted sources or the Internet.
5. V10.3.3: Verify that the application has protection from subdomain takeovers if the application relies upon DNS entries or DNS subdomains, such as expired domain names, out of date DNS pointers or CNAMEs, expired projects at public source code repos, or transient cloud APIs, serverless functions, or storage buckets (autogen-bucket-id.cloud.example.com) or similar. Protections can include ensuring that DNS names used by applications are regularly checked for expiry or change.

Business Logic

Beta Give feedback

1. V11.1.1: Verify that the application will only process business logic flows for the same user in sequential step order and without skipping steps.
2. V11.1.2: Verify that the application will only process business logic flows with all steps being processed in realistic human time, i.e. transactions are not submitted too quickly.
3. V11.1.5: Verify the application has business logic limits or validation to protect against likely business risks or threats, identified in the epic's risk assessment or threat modeling activities. Verify that all Github issues representing mitigating actions are closed.
4. V11.1.6: Verify that the application does not suffer from "Time Of Check to Time Of Use" (TOCTOU) issues or other race conditions for sensitive operations.
5. V11.1.7: Verify that the application monitors for unusual events or activity from a business logic perspective. For example, attempts to perform actions out of order or actions which a normal user would never attempt.
6. V11.1.8: Verify that the application has configurable alerting when automated attacks or unusual activity is detected.

Files and Resources

Beta Give feedback

1. V12.1.1: Verify that the application will not accept large files that could fill up storage or cause a denial of service.
2. V12.1.2: Verify that the application checks compressed files (e.g. zip, gz, docx, odt) against maximum allowed uncompressed size and against maximum number of files before uncompressing the file.
3. V12.1.3: Verify that a file size quota and maximum number of files per user is enforced to ensure that a single user cannot fill up the storage with too many files, or excessively large files.
4. V12.2.1: Verify that files obtained from untrusted sources are validated to be of expected type based on the file's content.
5. V12.3.1: Verify that user-submitted filename metadata is not used directly by system or framework filesystems and that a URL API is used to protect against path traversal.
6. V12.3.2: Verify that user-submitted filename metadata is validated or ignored to prevent the disclosure, creation, updating or removal of local files (LFI).
7. V12.3.3: Verify that user-submitted filename metadata is validated or ignored to prevent the disclosure or execution of remote files via Remote File Inclusion (RFI) or Server-side Request Forgery (SSRF) attacks.
8. V12.3.4: Verify that the application protects against Reflective File Download (RFD) by validating or ignoring user-submitted filenames in a JSON, JSONP, or URL parameter, the response Content-Type header should be set to text/plain, and the Content-Disposition header should have a fixed filename.
9. V12.3.5: Verify that untrusted file metadata is not used directly with system API or libraries, to protect against OS command injection.
10. V12.3.6: Verify that the application does not include and execute functionality from untrusted sources, such as unverified content distribution networks, JavaScript libraries, node npm libraries, or server-side DLLs.
11. V12.4.1: Verify that files obtained from untrusted sources are stored outside the web root, with limited permissions.
12. V12.4.2: Verify that files obtained from untrusted sources are scanned by antivirus scanners to prevent upload and serving of known malicious content.
13. V12.5.1: Verify that the web tier is configured to serve only files with specific file extensions to prevent unintentional information and source code leakage. For example, backup files (e.g. .bak), temporary working files (e.g. .swp), compressed files (.zip, .tar.gz, etc) and other extensions commonly used by editors should be blocked unless required.
14. V12.5.2: Verify that direct requests to uploaded files will never be executed as HTML/JavaScript content.

API and Web Service

Beta Give feedback

1. V13.1.1: Verify that all application components use the same encodings and parsers to avoid parsing attacks that exploit different URI or file parsing behavior that could be used in SSRF and RFI attacks.
2. V13.1.3: Verify API URLs do not expose sensitive information, such as the API key, session tokens etc.
3. V13.1.4: Verify that authorization decisions are made at both the URI, enforced by programmatic or declarative security at the controller or router, and at the resource level, enforced by model-based permissions.
4. V13.2.1: Verify that enabled RESTful HTTP methods are a valid choice for the user or action, such as preventing normal users using DELETE or PUT on protected API or resources.
5. V13.2.2: Verify that JSON schema validation is in place and verified before accepting input.
6. V13.2.5: Verify that REST services explicitly check the incoming Content-Type to be the expected one, such as application/xml or application/json.
7. V13.3.1: Verify that XSD schema validation takes place to ensure a properly formed XML document, followed by validation of each input field before any processing of that data takes place.
8. V13.3.2: Verify that the message payload is signed using WS-Security to ensure reliable transport between client and service.
9. V13.4.1: Verify that a query allow list or a combination of depth limiting and amount limiting is used to prevent GraphQL or data layer expression Denial of Service (DoS) as a result of expensive, nested queries.
10. V13.4.2: Verify that GraphQL or other data layer authorization logic should be implemented at the business logic layer instead of the GraphQL layer.

Configuration

Beta Give feedback

1. V14.2.3: Verify that if application assets, such as JavaScript libraries, CSS or web fonts, are hosted externally on a Content Delivery Network (CDN) or external provider, Subresource Integrity (SRI) is used to validate the integrity of the asset.
2. V14.2.4: Verify that third party components come from pre-defined, trusted and continually maintained repositories.
3. V14.2.6: Verify that the attack surface is reduced by sandboxing or encapsulating third party libraries to expose only the required behaviour into the application.
4. V14.4.1: Verify that every HTTP response contains a Content-Type header. Also specify a safe character set (e.g., UTF-8, ISO-8859-1) if the content types are text/*, /+xml and application/xml. Content must match with the provided Content-Type header.
5. V14.4.3: Verify that a Content Security Policy (CSP) response header is in place that helps mitigate impact for XSS attacks like HTML, DOM, JSON, and JavaScript injection vulnerabilities.
6. V14.4.4: Verify that all responses contain a X-Content-Type-Options: nosniff header. #483
   kind/user-story product/formidling product/meldingstjenesten +3
   
7. V14.4.6: Verify that a suitable Referrer-Policy header is included to avoid exposing sensitive information in the URL through the Referer header to untrusted parties.
8. V14.4.7: Verify that the content of a web application cannot be embedded in a third-party site by default and that embedding of the exact resources is only allowed where necessary by using suitable Content-Security-Policy: frame-ancestors and X-Frame-Options response headers.
9. V14.5.1: Verify that the application server only accepts the HTTP methods in use by the application/API, including pre-flight OPTIONS, and logs/alerts on any requests that are not valid for the application context.
10. V14.5.4: Verify that HTTP headers added by a trusted proxy or SSO devices, such as a bearer token, are authenticated by the application.