ShipSaving works diligently to ensure the confidentiality, integrity, and availability of your data.
- Encryption in transit protects the confidentiality, integrity, and authenticity of your data. As an industry best-practice, we use HTTPS to encrypt customer data sent and received by our servers. This includes, but is not limited to, all data transmitted over the RESTful JSON API that communicates with our backend microservice architecture. This protects your information from tampering and unauthorized disclosure. We also implement AES-GCM (an authenticated encryption algorithm based on a pre-shared key) to protect both the confidentiality and integrity of data transmissions.
- Database access controls restrict access to authorized users and IP addresses. Developers undergo strict account management. Auditing and robust log records provide relevant insights to personnel who regularly review database access for signs of malicious operation. Database passwords must adhere to internal standards for complexity. Database contents are encrypted both at rest and in transit.
- Field-level encryption with the AES-GCM algorithm protects sensitive database entries from unauthorized tampering or disclosure. When the application writes data to the database, sensitive fields are encrypted with an additional key. When the contents of an encrypted database field are retrieved, the results cannot be deciphered without the respective key. This second line of defense significantly reduces the potential impact of leaked data. Our software developers and database administrators (DBAs) operate by default on encrypted fields. Access to the original contents of encrypted fields is granted to staff only on a "need-to-know" basis.
- Data desensitization protects sensitive customer data such as phone numbers, email addresses, and payment card information. Predefined rules tokenize, hide, or mask this data. For extremely sensitive data such as payment card information, we only persist a subset of the original, significantly increasing customer safety.
Role-based access control (RBAC) assigns functional and data permissions to designated roles, and one or more roles to individual user accounts. A "super administrator," for instance, not only possesses global access to all actions and data, but will also typically customize other roles as needed and assign them to users. Our system administrators apply specific role assignments to customers. This ensures that customers possess functional authority and data authority over only their own data.
Malicious actions may attempt to tamper with input parameters to conceal executable commands or cross trust boundaries. This can lead to the unauthorized acquisition of server permissions and the unauthorized disclosure of customer data. The system addresses these concerns as follows:
- Buffer overflows occur when a system receives input of a length that overflows the memory area designated for its storage. A malicious user who succeeds at this attack may tamper with or expose data, or possibly gain system root access. To avoid receiving data that exceeds system capacity, we treat external data as untrusted input and perform boundary checks before committing to our systems.
- Cross-site request forgery (CSRF) can occur when an attacker causes a victim's browser to automatically submit a request. This attack is similar to, but different from, a cross-site scripting (XSS) attack. In the case of CSRF, the attacker crafts a malicious request directed at a particular website. If the customer has an active browsing session on that website, the request can be executed to create, read, update, or delete data as the customer themselves. This is equivalent to the attacker logging in with the customer's own credentials to carry out harmful actions within the scope of the customer's authority. To prevent CSRF attacks and protect customer accounts, the system validates CSRF tokens, HTTP referer headers, and CAPTCHA responses.
- Path traversal can occur when query parameters and server paths are not properly sanitized or validated before use in accessing a server-side file system location. An attacker may supply a string with directory navigation operators, possibly escaped (e.g., "../" or "%2E%2E%2F"), to gain unauthorized access to information systems. To prevent this, all customer input is validated and/or escaped after transmission.
- A web shell is a type of remote access trojan (RAT) that exploits a script upload vulnerability to create a command execution environment. An attacker will often use this shell environment through a web browser. This can lead to a series of hazards such as unauthorized information disclosure and tampering. To avoid receiving a web shell, we strictly limit and verify uploaded files. Customers may upload only static files and the system does not trust original filenames. In addition to restricting the upload of malicious code files, the system restricts the execution permissions of related directories.
- Unexpected data disclosure may occur when access logs record sensitive query parameters. To prevent this, the HTTP GET method is not used to transmit sensitive data into the system. When sensitive data must be transmitted into the system, the HTTP POST method is used, and sensitive data placed in the body of the request. The HTTP GET method may be used to transmit non-sensitive data to the system, and to retrieve both sensitive and non-sensitive data from the system.
Customer password security promotes not only the security of customer information on our platform but also the stability of the system as a whole. Some customers may use the same password on multiple platforms; once this password is cracked, the risk of data leakage exists on any other platforms with which it is shared. We mitigate the potential for damage as follows:
- The system assigns an authentication token to customers at login. This token accompanies the customer throughout their session and grants the ability to access assigned functions and data. The system reduces the potential for unauthorized disclosure or tampering by requiring a valid token with requests for privileged functions and data.
- User authentication checks occur with every request. We encourage customers to log out manually when they are finished with the system. As a protection against abandoned sessions, if authentication credentials expire or the authentication process fails, the customer will be required to log in again to minimize the potential for data leakage.
- The AES-GCM encryption algorithm promotes authenticity in the system with authentication codes and authenticated encryption with associated data (AEAD). If system decryption functions note authenticity issues during the decryption process, an exception will be thrown to prevent further processing of corrupted or tampered customer data.
- Customer password length and complexity requirements mitigate the likelihood of brute-force password cracking. We guarantee that customer passwords are not stored in plaintext. Customer passwords are salted and hashed on the frontend with a slow hash operation. Sensitive data, including authentication credentials, will be transmitted to the backend only over a connection encrypted with HTTPS.
- Two-factor verification validates customer ownership of email addresses used for website authentication. When we detect a customer account at risk of misappropriation, the affected customer must correctly supply both their password and a one-time code that the system will send to their email address. CAPTCHA affords an additional layer of protection for this process.
We are continuously strengthening our product security controls to ensure the maximum confidentiality, integrity, and availability of customer accounts and data.
- The vast majority of customer operations trigger the creation of audit logs. This provides customers the ability to trace events when necessary. We provide operation logs for each event that include a timestamp, customer ID, the object being operated on, and the contents of the operation. To facilitate unified management, system administrators have the ability to view the operation logs of all customers.
- We record operations performed by customers on their own data. If an operation involves sensitive data, such as password or payment card information, metadata attached to log entries will be encrypted to minimize the potential for data leakage.
- Customer requests for data will be approved or denied based upon credentials and additional security considerations. The results of these decisions will be recorded.
- Multiple customer user accounts may collaborate as a team. In these cases, a team administrator may be designated as an approver for purchase orders placed by other team members. For example, a warehouse manager who wishes to create a purchase order will submit an application to their administrator for approval. The administrator can then choose to deny or approve the application. If the application is approved, the purchase order will be created. The system records these decisions with per-application granularity.
- Potentially risky operations trigger alarms to be handled by dedicated personnel.
- Logs are retained for 180 days.
- Developers are subject to sound auditing and log management. We mitigate the potential for developer credential misuse by logging the following events:
- Login and logout timestamps;
- Database and server access attempts;
- Data, file, and network access attempts;
- Changes to customer data, such as deletion or modification of sensitive info;
- Exceptions or other signs of abnormal activity, which may trigger alarms.
Our customers fulfill orders with the aid of transactional and other data ("Platform Data") synchronized into our system from third-party e-commerce platforms ("Marketplaces"). To ensure the availability of Platform Data when it is needed, we perform regular backups. Each Marketplace imposes its own policies on the use, protection, and retention of Platform Data.
ShipSaving treats Platform Data, and backups thereof, in strict accordance with the requirements of each Marketplace. We do not maintain Platform Data beyond the retention periods mandated by Marketplaces. We do not sell, share, or otherwise disclose customer data in any manner that would violate our agreements with Marketplaces.
- Full database backups occur weekly at 23:59 on Sunday.
- Incremental database backups occur daily at 03:00, 09:00, 15:00, and 21:00.
- The database currently utilizes master-slave synchronization to promote data redundancy. Binary logging on the slave database is enabled for off-site backup.
- Future plans include database read-write separation ("master write, slave read") to promote scalability and high-availability. This master-slave synchronization architecture, with backups in accordance with the original backup scheme, may entail a split into separate databases and additional tables to further improve the ShipSaving recovery time objective (RTO) and recovery point objective (RPO) metrics.
security incident response plan (SIRP)
We maintain a security incident response plan (SIRP) and we review and verify this plan every six months and after any major infrastructure or system change. When our backend engineering managers investigate security incidents, or when automation mechanisms trigger an alarm.
- We identify the type and extent of any associated events.
- We disconnect any relevant systems from the network.
- We gather evidence. System logs may be viewed without shutting down associated servers, which promotes forensic analysis of potential evidence in memory, if required.
- In the event that a breach may affect passwords, we will lock down sensitive information and rotate any relevant passwords.
- The impact of a data breach will be assessed based upon logs and other available evidence. Once a root cause analysis is performed, remedial measures will be taken. These may include, but are not limited to, cryptographic erasure of affected systems, patching of relevant software or operating systems, reconfiguration of firewalls, isolation of subnets, malware scanning, and recalibration of automated alarm thresholds.