SkylineGlobe Server Data Protection

Before each release of SkylineGlobe Server, Skyline conducts penetration testing to detect and mitigate potential security risks. This comprehensive test identifies vulnerabilities such as SQL injection, XSS, CSRF, and XXE attacks. It evaluates session management, cryptographic integrity, secure communication, directory security, parameter integrity, and access controls. 

In this article:

• Session Management
• Access Control
• Input Validation
• Error Handling and Logging
• Data Protection
• Malicious Code Protection
• Business Logic
• Files and Resources
• Web Services
• Configuration
• Authentication

Session Management

Fundamental Session Management 

• Token Visibility: SGS ensures that session tokens are never revealed in URL parameters or error messages.

Session Binding 

• Token Generation: SGS generates a new session token upon each user authentication.
• Token Entropy: Session tokens have at least 64 bits of entropy to ensure sufficient randomness and security.
• Token Storage: Session tokens are stored in the browser using secured cookies to prevent unauthorized access.

Cookie-Based Session Management

• Secure Attribute: Cookie-based session tokens have the 'Secure' attribute set, so that they can only be sent over HTTPS.
• HttpOnly Attribute: Cookie-based session tokens have the 'HttpOnly' attribute set to prevent access by client-side scripts, reducing the risk of cross-site scripting (XSS) attacks.
• SameSite Attribute: Cookie-based session tokens have the 'SameSite' attribute set to restrict the sending of cookies along with cross-site requests, enhancing protection against cross-site request forgery (CSRF).

Defenses Against Session Management Exploits

• Sensitive Transactions: SGS ensures a valid login session, re-authentication or secondary verification before allowing any sensitive transactions or account modifications.

Access Control

General Access Control Design

• Trusted Service Layer: SGS ensures that access control rules are enforced on a trusted service layer to prevent unauthorized access via manipulation of the client-side application.
• Attribute Integrity: All user and data attributes, along with policy information used by access controls, cannot be manipulated by end users unless specifically authorized.
• Minimum Necessary Access: SGS adheres to the principle of least privilege, ensuring that users can only access functions, data files, URLs, controllers, services, and other resources for which they have been specifically authorized. 
• Deny by Default: SGS implements a 'deny by default' strategy where new users and roles start with minimal or no permissions. Access to functions and features is only granted after explicit assignment.
• Generic Error Messages: Users are redirected to a generic error message page when exceptions occur to prevent leakage of sensitive information through error outputs.

Operation Level Access Control

• Insecure Direct Object References (IDOR): Sensitive data and APIs are protected against Insecure Direct Object References by ensuring that direct object references do not expose access to unauthorized data (e.g., preventing a user from accessing another user's data by simply modifying a parameter in the URL).
• Anti-CSRF Mechanisms: SGS enforces strong anti-CSRF (Cross-Site Request Forgery) mechanisms to protect authenticated sessions and functions. Anti-CSRF tokens are used to mitigate potential CSRF attacks.

Other Access Control Considerations

• MFA: SSO defines authentication protocol for all users.
• Directory Browsing Disabled: Directory browsing is disabled and discovery or listing of files and directories is not allowed.

Input Validation

Input Validation 

• Protection Against Mass Assignment: SGS protects against mass parameter assignment attacks, which could allow attackers to manipulate inputs such as adding multiple email addresses to a single user email ID field.
• Data Requirement Validation: SGS validates and accepts data based on specific requirements, e.g., ZIP codes are required to consist only of a fixed number of digits.

Sanitization and Sandboxing 

• Input Parameter Restrictions: Maximum length restrictions are enforced for all input parameters to prevent buffer overflow attacks.
• Dynamic Code Execution Protection: Dynamic code execution commands, such as Command/OS Injection commands like "whoami", "ipconfig", or "pwd" are not accepted.
• Template Injection Protection: Protection against template injection attacks is enforced.

Output Encoding and Injection Prevention

• Output Encoding and Escaping: SGS implements output encoding and escaping to protect against reflected, stored, and DOM-based XSS.
• Use of Parameterized Queries: SGS employs parameterized queries to prevent SQL injection attacks. When parameterized queries are not viable, it uses output encoding to protect against injection attacks.
• Protection Against Various Injection Attacks: SGS guards against OS command injection and Local or Remote File Inclusion (LFI/RFI) attacks, and against XPath injection or XML injection attacks.

Deserialization Prevention

• Safe Deserialization Practices: SGS avoids deserialization of untrusted data and ensures it is adequately protected in both custom code and third-party libraries, including those handling JSON, XML, and YAML.
• Secure JSON Parsing: When parsing JSON in browsers or JavaScript-based backends, JSON.parse is used to parse JSON documents and  eval() is avoided.

Error Handling and Logging

Log Content 

• Protection of Sensitive Information: SGS ensures that credentials or payment details are not logged in clear text. Session tokens are stored in an irreversible, hashed form to protect against unauthorized access.
• Compliance with Privacy Laws: No sensitive data, as defined under local privacy laws or relevant security policies, is logged. 

Error Handling

• Generic Error Messages: A generic error message is displayed to the user when an unexpected or security-sensitive error occurs. This prevents potential attackers from gaining insights into the application architecture or discovering vulnerabilities based on detailed error messages.

Data Protection

Client-Side Data Protection

• Sensitive Data in Client Storage: SGS ensures that no sensitive data or Personally Identifiable Information (PII) is stored in client-side storage.

Sensitive Private Data

• Secure Data Transmission: Sensitive data is transmitted securely by sending it only in the HTTP message body, not in URLs.
• User Data Control: Users are provided with methods to remove or export their data on demand, enhancing transparency and control over their personal information.
• Informed Consent: User data is not used or any other purpose. 
• Sensitive Data Policy: Comprehensive policy enforced on the management and protection of sensitive data, that details procedures for handling, storing, and deleting sensitive data securely.

Malicious Code Protection

Deployed Application Integrity Controls

• Integrity Protections: SGS employs robust integrity protections, such as code signing and sub-resource integrity. SGS strictly avoids loading or executing code from untrusted sources.
• Protection from Subdomain Takeovers: SGS has protective measures against subdomain takeovers.

Business Logic

• Sequential Process Enforcement: SGS follows a defined sequence of steps without skipping any steps during critical processes, such as login.

Files and Resources

File Execution 

• File Name Validation: SGS enforces strict validation and sanitization of user-submitted filename metadata to prevent path traversal, Local File Inclusion (LFI), Remote File Inclusion (RFI), Server-side Request Forgery (SSRF), and Reflective File Download (RFD). This includes not using filenames directly in filesystem operations, blocking external file executions, and ensuring safe download practices by setting appropriate response headers.
• Protection Against OS Command Injection: SGS implements protection to prevent OS command injection attacks.

File Download

• Valid File Extensions: Only required file extensions are accepted, e.g., only .jpg, .png or .jpeg ext for image uploads.

Web Services

Verification Requirements

• Encoding Consistency: All SGS components utilize identical encodings and parsers, mitigating the risk of parsing attacks.
• Restricted Access: Access to administrative and management functions is strictly limited to authorized personnel only.
• HTTP Method Restrictions: Unnecessary HTTP methods are disabled to enhance security.
• JSON Validation: JSON schema validation is implemented to ensure all input characters are properly verified.
• XML Validation: XSD schema validation is applied to every XML document input field, ensuring compliance and security.

Configuration

Dependency

• Removal of Unnecessary Files: All sample documentation, test files, and any other non-essential files have been removed.
• Subresource Integrity: All assets, such as JavaScript libraries, CSS stylesheets or web fonts, are hosted externally on a content delivery network (CDN) or external provider. Subresource Integrity (SRI) checks are implemented.

Unintended Security Disclosure 

• Generic Error Messages: Generic web and application server and application framework error messages are displayed that do not reveal specifics about the underlying architecture or software versions.
• Debug Modes: Web or application server and application framework debug modes are disabled in production environments.
• HTTP Headers Security: No detailed version information of the server, application framework, or other system components is disclosed in HTTP headers.

HTTP Security Headers 

• Content-Disposition Header: All API responses contain Content-Disposition: attachment; filename="api.json" header (or other relevant filenames based on content type).
• Content Security Policy (CSP) Header: CSP header implemented that mitigates XSS attacks through HTML, DOM, JSON, and JavaScript injection vulnerabilities.

Validate HTTP Request Header 

• HTTP Methods Restriction: SGS accepts only the HTTP methods actively used by the application/API.

Authentication through Single Sign-On (SSO) 

The authentication security standards listed below are fulfilled by Single Sign-On (SSO) user authentication. SkylineGlobe Server (SGS) can be connected to any external identity provider (idP) that supports the Open ID protocol to provide SSO authentication control. Check that your SSO provider offers the necessary features to meet your requirements.

Password Security Credentials

• SSO Implementation: SGS provides both a user/pass option and a Single Sign-On (SSO) option. If the SSO option is used, authentication is controlled by the SSO provider under its rules. SGS also provides a simpler user/pass and token mechanisms. 

Authenticator Lifecycle 

• System-Generated Passwords: Initial passwords or activation codes are securely randomly generated, at least six characters long, alphanumeric, and expire after a short period.

Credential Recovery 

• Secure Delivery: Initial activation or recovery secrets are sent via a secure platform like Thycotic Vault.
• Password Recovery: Password recovery processes do not reveal the current password. Password hints or knowledge-based authentication (so-called "secret questions") are not used.
• Notification on Changes: Users are notified of any changes or replacements to their authentication factors.
• Secure Recovery Mechanism: Forgotten password and other recover paths use a secure recovery mechanism, such as time-based OTP or other soft token, mobile push, or other offline recovery mechanism. Time-based OTP's have a defined lifetime before expiring.