AWS m2 documentation change
Summary
Added a new 'Security' section with 10 FAQs addressing various security protections including SQL injection prevention, command injection mitigation, XSS protection, CSRF defense, and session security measures.
Security assessment
The changes exclusively document existing security features and protections (prepared statements, input validation, framework capabilities) without referencing any specific vulnerability fixes or security incidents. No evidence of addressing a disclosed vulnerability exists in the diff.
Diff
diff --git a/m2/latest/userguide/ba-faq.md b/m2/latest/userguide/ba-faq.md index fbc538426..95248cf0a 100644 --- a//m2/latest/userguide/ba-faq.md +++ b//m2/latest/userguide/ba-faq.md @@ -5 +5 @@ -GeneralAWS Blu Age RuntimeDataTransformationDeployment +GeneralAWS Blu Age RuntimeDataTransformationDeploymentSecurity @@ -383,0 +384,53 @@ It is integrated with Control-M /Stone branch or with any other Distributed sche +## Security + + 1. **How does the application protect against SQL injection attacks?** + +The application implements SQL best practices throughout. All database queries use prepared statements, which effectively prevent SQL injection attacks by separating SQL code from user supplied data. This ensures that user input is always treated as data rather than executable code. + + 2. **What measures are in place to prevent OS command injection vulnerabilities?** + +AWS security teams conduct regular security reviews of AWS Blu Age Runtime. If the teams detect any anomalies such as code that could potentially allow OS command injection, AWS immediately works to resolve. This continuous monitoring ensures that the runtime remains secure against command injection threats. + + 3. **Is the application vulnerable to directory traversal attacks?** + +No. This vulnerability does not apply to the front-end Angular application. For the back-end, the application uses only one endpoint with a limited interface contract that never contains "path" or "directory" information. This design eliminates the risk of directory traversal attacks. + + 4. **How does the application protect against XSS attacks?** + +The application follows Angular security best practices as described in the official [Angular security documentation](https://angular.dev/best-practices/security). The application's nature is inherently limited in terms of UI since it corresponds to the legacy mainframe application. The application handles no URLs, dynamic scripts, or HTML generated by the back-end. This limited attack surface significantly reduces XSS risks. + + 5. **What protection is implemented against CSRF attacks?** + +The application utilizes Spring's native [CSRF support](https://docs.spring.io/spring-security/reference/servlet/exploits/csrf.html), which provides robust protection against cross-site request forgery attacks out of the box. + + 6. **Can user input lead to HTTP header injection?** + +No. User inputs are strictly limited in length to match the legacy mainframe application format. When the back-end receives a request, it immediately formats the input according to predefined formats, which would truncate any injected content. Additionally, the application never constructs HTTP headers based on user inputs in the single endpoint used by the application, making HTTP header injection impossible. + + 7. **How is the application protected against clickjacking attacks?** + +The application performs most actions using keystrokes rather than mouse clicks, making it inherently resistant to clickjacking attacks. This design choice significantly reduces the attack surface for this type of vulnerability. + + 8. **Can buffer overflow attacks occur in the application?** + +No. User inputs are strictly limited in length to correspond with the legacy mainframe application format. When the back-end receives a request, it immediately formats the input according to the corresponding formats, preventing buffer overflow conditions from occurring. + + 9. **How are access control and authorization managed?** + +Access control determines globally whether users have rights to access the unique back-end endpoint. Once authenticated, the application code and data handle authorization controls. This ensures proper separation of concerns and secure access management. + + 10. **What measures prevent session hijacking?** + +The combined use of Spring and Angular native capabilities for session management and XSS prevention, along with adherence to framework best practices, prevents session hijacking. The application can further enhance protection by: + + * **Using HTTPS** : Ensures all communication is encrypted. + + * **Implementing Token-Based Authentication** : The application can activate this when needed. + + * **Monitoring User Sessions** : The application can activate session monitoring and anomaly detection to identify suspicious activity. + +These layered security measures provide comprehensive protection against session hijacking attempts. + + + +