The security checklist makes it possible for developers to learn and practice properly.
|IDS||Unrestricted File Upload like Exitf, shell script attack. |
– Owasp Unrestricted_File_Upload
– 5 ways to File upload vulnerability Exploitation
– Protect FileUpload Against Malicious File
– Input Validation and Data Sanitization (IDS)
|HTTP Headers||– Content-Security-Policy|
e.g For Nginx configuration example:
add_header X-Frame-Options “SAMEORIGIN” always;
add_header X-Xss-Protection “1; mode=block” always;
add_header X-Content-Type-Options “nosniff” always;
add_header Strict-Transport-Security “max-age=31536000; includeSubdomains” always;
add_header Content-Security-Policy “default-src ‘self’ https:; data: https://*; …”
add_header Referrer-Policy “no-referrer” always;
add_header Feature-Policy “accelerometer ‘none’; camera ‘none’; geolocation ‘none’; gyroscope ‘none’; magnetometer ‘none’; microphone ‘none’; payment ‘none’; usb ‘none'” always;
The online audit provided by https://securityheaders.com/
|JWT||– Expiry is hardcoded should be dynamic.|
– Key creation should follow a private key derivation externally hosted to be changed immediately if the security is compromised
– Make sure that no critical information as the token value is displayed in the server-side log
– JWT’s should include an identifier detailing which app generated the token. For example, if your JWT’s are being created by 2 different clients, mychat, and myclassifiedsapp, then each should include its project name or something similar in the “iss” field in the JWT e.g. “iss”:”mychat”
– The value of aud in the ID token is equal to one of your app’s client IDs. This check is necessary to prevent ID tokens issued to a malicious app being used to access data about the same user on your app’s backend server.
– JWT supports a “none” algorithm. If the alg field is set to “none”, any token would be considered valid if their signature section is set to empty.
– API2:2019 — Broken authentication
– Critical vulnerabilities in JSON Web Token libraries
– Attacking and Securing JWT
– Best practices for server-side handling of JWT tokens
|Daemon||The daemon is running as root! That’s critical and needs to be changed. For example:|
[root@ip-192-11-22-158 ~]# ps -eaf | grep java
root 21767 1 0 2018 ? 00:00:00 sudo java -DkeepAliveTimeout=500000 -Dfile.encoding=UTF-8 -Xmx256M -jar target/myapp.jar
|Hardcoded access||– Passwords and access are hardcoded in file configuration.|
– It is recommended to have them set by using env variables that are deleted as soon as used. So access is only available in the memory process, and quite harder to get.
– how to use Environment Variables keep your secret keys safe & secure.
|HTTPS/SSL||– SSL protocol support versions: TLSv1.3 TLSv1.2 TLSv1.1 TLSv1;|
– Nginx server configuration if the certificate chain is incomplete., SSL certificate chains. For instance:
ssl_protocols TLSv1.2 TLSv1.1 TLSv1;
ssl_ciphers “EECDH+ECDSA+AESGCM …”;
– Online SSL Test at https://www.ssllabs.com/ssltest/index.html
|PCI||Payment Card Industry (PCI). All Security Payment Data includes card numbers, ID/Passport, Social Insurance Number,.. by strong cryptography algorithms e.g AES-128, AES-256|
– PCI-DSS_v3.2.1 issued by https://www.pcisecuritystandards.org/
|Linux||– The good security practice should enable SELinux|
– Manage open/close ports. For example, in Redhat 7.x
iptables -A IN_public_allow -p tcp –dport 5432 -j ACCEPT
iptables -A IN_public_allow -p tcp –dport 5432 -j DROP
– UNIX Permissions. Be aware of chmod 777 . Change owners of files or folders by users/groups.
Some other useful references: