Security Requirements
V2 Authentication requirements
2.1 Password security requirements
AASI.net have two authentication/authorization providers, they are: Accounts and EntraID; the first is managed in production by the NAD Team, and the second by IATec-BR.
2.1.1. How are the user's definitions defined as having at least 8 characters (apart from a combination of several spaces)?
| Accounts | Microsoft Entra ID |
|---|---|
| The user password has eight characters after combining multiple spaces. | The user password has eight characters after combining multiple spaces. |
2.1.3. Has the password truncation not been executed? However, several consecutive spaces can be replaced by a single space.
| Accounts | Microsoft Entra ID |
|---|---|
| The passwords are not truncated, but if they have many spaces, all of them are replaced by one. | The passwords are not truncated, but if they have many spaces, all of them are replaced by one. |
2.1.4. Are any printable Unicode characters, including language-neutral characters like spaces and Emojis, allowed in passwords?
| Accounts | Microsoft Entra ID |
|---|---|
| Yes, All of them are allowed | Partially yes, emojis are not allowed. |
2.1.5. Can users change their passwords?
| Accounts | Microsoft Entra ID |
|---|---|
| Yes, AASI .net provide them with a custom interface. | Yes, they can, but from a Microsoft interface called "My Account". |
2.1.6. Does the password change functionality require the user's current and new password?
| Accounts | Microsoft Entra ID |
|---|---|
| Yes, the user needs to write the current and new password. | Yes, the user needs to verify its authentication login again or use its two-factor authentication method. |
2.1.9. Are there no password composition rules limiting the type of characters allowed? There should be no limitations on the inclusion of upper or lower-case letters, numbers or special characters.
| Accounts | Microsoft Entra ID |
|---|---|
| There are no password composition rules that limit the type of characters allowed... There should be no limitations on the inclusion of upper or lower-case letters, numbers or special characters. | There are no password composition rules that limit the type of characters allowed... There should be no limitations on the inclusion of upper or lower-case letters, numbers or special characters. |
2.1.11. Are "paste" functionality, browser password helpers, and external password managers allowed?
| Accounts | Microsoft Entra ID |
|---|---|
| Yes, the paste password functionality is allowed. | Yes, the paste password functionality is allowed. |
2.2 Password recovery requirements
2.5.2 Are password hints or knowledge-based authentication (so-called "secret questions") not present?
| Accounts | Microsoft Entra ID |
|---|---|
| There is no secret question or other knowledge-based method. | There is no secret question or other knowledge-based method. |
2.5.3 Does password credential recovery not reveal the current password in any way?
| Accounts | Microsoft Entra ID |
|---|---|
| The password recovery method does not reveal the current password. | The password recovery method does not reveal the current password. |
2.5.4 Are shared or default accounts not present (e.g., "root", "admin", or "sa")?
| Accounts | Microsoft Entra ID |
|---|---|
| There are no standard accounts like admin, root or other. | There are no standard accounts like admin, root or other. |
V3 Session Management Verification Requirements
3.1 Fundamental Session Management Requirements
3.1.1 The application never put the session token in the URL, because it is stateless, all session is built with the authentication token and it is sent via http headers.
3.2 Session Binding Requirements
3.2.1 The application generates the token in each authentication process.
3.2.2 The session tokens have more than 64 bits of entropy.
3.3 Logout requirements and session timeout
3.3.1 Logout and expiration invalidate the session token, so the Back button or a trusted user will not resume an authenticated session, even between trusted users.
3.3.2.1 The re-authentication occurs in these cases:
- When the browser freezes the tab and the token expires.
- When the token is not destroyed (logout).
- When the browser has a valid refresh token in all cases.
V4 Requisitos de verificación del control de acceso
4.1 General access control project
4.1.1 The application applies access control rules at a trusted services layer, especially if client-side access control is present and can be bypassed.
4.1.2 All user attribute data and policy information used by access controls cannot be manipulated by end users... Unless specifically authorized.
4.1.3 Yes, we implemented the Role-Based Access Control and an Access Control List for execution permissions provided by DSA.
4.1.5 The application has a good resilience recovery method when some bug happens. The access control is in the top layer of our architecture.
4.2 Operation level access control
4.2.1 Sensitive data and APIs are protected against Insecure Direct Object Reference (IDOR) attacks
4.2.2 We use a stateless model and CSRF is not possible. Because all sessions will need a valid authentication token generated by a valid user/password combination.
4.3 Other considerations about access control
4.3.2 Directory browsing is disabled on our servers as is directory climbing.
V5: Validation, hygiene and coding verification requirements
5.1 Entry validation requirements
5.1.1 All our parameters are validated at the top of application execution.
5.1.2 Partially our parameters are parsed to class and it has only the functionality data and meta specification.
5.1.3 All input requests are validated, from API, files, batch files and custom http headers.
5.1.4 All structured data is validated when they will be used for transactions or other relevant processes.
5.1.5 The redirections are allowed only in the authentication and it is validated and restricted.
5.2 Sanitation and sandbox requirements
5.2.1 We validate WYSIWYG data with tools provided by Angular.
5.2.3 We have our email queue, and it cleans, verifies and shows logs when the email is not valid.
5.2.4 In the FrontEnd we avoid using the Javascript eval function. In the BackEnd, we do not have the compiler assemblies.
5.2.5 We do not allow writing templates, all inputs are evaluated as primitive types and they are not executed or built.
5.2.7 Our JS chunks have a particular structure to prevent this kind of manipulation. On the other hand, our SVG comes from API because we are using this strategy for changing the colours.
v5.2.8 Scripts and other interpreted languages are insolated in containers that do not interact with the main functionality.
5.3 Output encoding and injection prevention requirements
5.3.1 All our data is encoded on utf-8 and all input data is transformed to this encode by our ORM.
5.3.2 The output encoding preserves the user's chosen character set and locale for any valid Unicode character.
5.3.4 All data that interact with SQL sentences are provided via parameters to the main SQL query, our ORM sanitizes them.
5.3.6 All JSON data is destructured to classes, and in this process, the execution of JS code is not allowed.
5.3.8 The OS code injection method is preserved by our framework.
5.3.9 We read the files as a bytes array, and it is parsed to string, we do not execute or read the user files in the serve, so the Local File Inclusion is not possible.
5.3.10 We validate the XML code in our external systems endpoints under a specific structure, any extra code is allowed.
5.3 Deserialization Prevention Requirements
5.5.2 The application correctly restricts XML parsers to use only the most restrictive settings possible and to ensure unsafe functions such as external entity resolution.
5.5.3 The deserialization of unreliable JSON and XML is evaluated using a third-party library.
5.5.4 We all the time are using JSON.parse, we avoid using of eval function.
V7: Error Handling and Log Checking Requirements
7.1 Record Content Requirements
7.1.1 The application does not store credentials or payment details.
7.1.2 The application does not record other sensitive data as defined in local privacy legislation or in the relevant security policy.
7.4 Error Handling
7.4.1 A generic message is displayed when an unexpected or security-sensitive error occurs.
V8: Data Protection Verification Requirements
8.2 Client-side data protection
8.2.1 We use the corresponding headers only on static files and specific images for caching, everything else is not cached.
8.2.2 Data stored in browser storage (such as localStorage, sessionStorage or IndexedDB) does not contain sensitive user data.
8.2.3 Authenticated data is removed from client storage, such as the browser's DOM, after the session has ended.
8.3 Confidential private data
8.3.1 Sensitive data is sent to the server in the HTTP message headers. The query params of any HTTP verb do not contain sensitive data.
8.3.3 Users are provided with clear information regarding the use of the personal information they provide. Users have given their consent for the use of this data before it is used in any way.
V10: Malicious Code Scanning Requirements
10.3 Deployed application integrity controls
10.3.2 The application does not implement a plugins/addon system, any external code that get resources from the internet, only gets resources from our servers.
V11: Business Logic Verification Requirements
11.1 Business Logic Security Requirements
11.1.1 The application will only process business logic flows for the same user in sequential order of steps and without skipping steps.
11.1.2 The application will only process business logic flows with all steps being processed in realistic human time.
11.1.3 The application has appropriate limits for specific business actions or transactions that are correctly enforced on a per-user basis. We have timeouts configured.
11.1.4 In the FrontEnd we have implemented a control to avoid multi-click, but if someone calls our endpoints, they try to respond. It should be noted that AASI.net is the back of a Reverse Proxy with this kind of protection.
V12: File and Resource Verification Requirements
12.1 File upload requirements
12.1.1 The application does not accept large files that could fill up the storage or cause a denial of service. The max length is 5 MB.
12.3 File execution requirements
12.3.1 AASI .net API is protected against path or directory traversal vulnerability.
12.3.2 The file metadata is only used as a string because the file has an internal name.
12.3.3 The uploaded files are not used or executed directly Forgery is not possible.
12.3.4 The files are validated a never are executed or served directly, all the time it is manipulated as byte array or as string. The file name internally is a GUID, and the probability of generating a duplicated GUID is 1% because it has high entropy (128 bits).
12.4 File Storage Requirements
12.4.1 All persistent uploaded files are stored in AWS S3 and they are read-only. The temp files are marked as read-only too, and they are deleted after use.
12.5 File Download Requirements
12.5.1 AASI .net does not allow files from webcams. 12.5.2 Direct requests for uploaded files will never be executed as HTML/JavaScript content.
V13: Business Logic Verification Requirements
13.1 Generic Web Services Security Verification Requirements
13.1.1 All application components use the same encodings and parsers to prevent parsing attacks that explore different URL or file parsing behaviours that can be used in SSRF and RFI attacks.
13.1.3 API URLs do not expose sensitive information such as API keys, session tokens, etc without authentication.
3.2 RESTful Web Service Verification Requirements
13.2.1 The DELETE or PUT actions via API implement the access control too. Only authorized users can execute these actions.
13.2.2 JSON schema validation is in effect and verified before accepting an input.
13.2.3 AASI .net does not use sessions based on cookies.
V14: Configuration Verification Requirements
14.2 Dependence
14.2.2 All unnecessary resources, documentation, sample applications and settings have been removed.
14.4 HTTP Security Headers Requirements
14.4.1 Each HTTP response contains a valid Content-Type header. Also specify a safe character set (e.g. UTF-8, ISO-8859-1)
14.4.2 All API responses contain the header Content-Disposition: attachment; filename="api.json" when the response is a file.
14.4.5 A Strict-Transport-Security header (forces HTTPS) is included in all responses and for all subdomains, such as Strict-Transport-Security: max-age=15724800; include Subdomains
14.4.6 A proper Referrer-Policy header is included to prevent exposing sensitive information in the URL via the Referer header to untrusted parties.
14.4.7 X-Frame-Options is configured in our headers, but Content-Security-Policy still no.
14.5 Validate HTTP Request Header Requirements
14.5.1 The application server accepts only 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.
14.5.2 The provided Origin header is not used for authentication or access control decisions. Because the Origin header can be easily altered by an attacker.
14.5.3 The Cross-Origin Resource Sharing (CORS) Access-Control-Allow-Origin header uses a strict allowlist of trusted domains and subdomains to match and does not support "null" origin.