Beveiliging


Hieronder kunt u een aantal beveiligings maatregelen vinden die kunnen worden toegepast voor uw webapplicatie. Dit is slechts om u een klein idee te geven over de mogelijkheden op het gebied van beveiliging. Uiteraard zijn er ook ander beveiligings maatregelen die toegepast kunnen worden. Hieronder een checklist met maatregelen die in veel situaties getroffen moeten worden (deze kunnen trouwens per webapplicatie verschillen).

Wordpress Security Checklist


PHP based application level firewall voor protectie tegen:
– [   ] SQL injection, XSS (Cross site scripting), Malicious file upload, Directory traversal, Local file inclusion, XXE (External entity expansion)

404 Detectie:
– [   ] 404 detectie kijkt naar gebruikers die een groot aantal niet-bestaande pagina’s probeert te bezoeken en hierdoor een groot aantal 404-fouten krijgt. 404 detectie neemt aan dat een gebruiker die in korte tijd veel 404-fouten krijgt, ergens naar op zoek is (waarschijnlijk een kwetsbaarheid) en sluit hen daardoor uit. Dit heeft als bijkomend voordeel dat je geholpen wordt bij het vinden van verborgen problemen die 404-fouten veroorzaken op ongeziene delen van je site.

Brute force beveiliging:
– [   ] Als iemand onbeperkt tijd zou hebben en een onbeperkt aantal wachtwoordcombinaties wou willen proberen om in je site te komen, zou het ze uiteindelijk lukken, toch? Deze methode van aanvallen, bekend als brute force aanval, is iets waarvoor WordPress vatbaar is omdat, standaard, het systeem niet uitmaakt hoeveel pogingen een gebruiker doet om in te loggen. Login limieten zal de host gebruiker verbannen opnieuw in te loggen nadat een gespecificeerd aantal foute inlogpogingen is bereikt.

Bestandswijzigingen detectie:
– [   ] Zelfs de beste beveiligingsoplossingen kunnen falen. Hoe weet je of iemand je site is binnengedrongen? Je weet het omdat zij iets zullen wijzigen. Bestandswijziging detectie zal je vertellen welke bestanden zijn gewijzigd binnen je WordPress installatie, je hiermee op de hoogte stellend van wijzigingen die je zelf niet hebt uitgevoerd. In tegenstelling tot andere oplossingen, kijkt het alleen naar je eigen installatie en vergelijkt deze met de vorige controle, in plaats van je bestanden te vergelijken met een andere installatie, daarbij rekening houdend met eerdere wijzigingen die je zelf hebt uitgevoerd.

Bestandspermissies:
– [   ] Veilige bestandsrechten voor bepaalde wordpress bestanden zoals wp-config.php en .htaccess (chmod 444).

Verbergen Backend:
– [   ] Verbergt de login pagina (wp-login.php, wp-admin, admin en login) waardoor deze moeilijker vindbaar word voor geautomatiseerde aanvallen.

Gedwongen SSL:
– [   ] Secure Socket Layers (SSL) is een technologie die word gebruikt om de data die tussen je server of host en een bezoeker van je webpagina te versleutelen. Wanneer SSL is geactiveerd, maakt dit het nagenoeg onmogelijk voor een aanvaller om de data tijdens verzending te onderscheppen, waarmee de verzending van formulieren, wachtwoorden of andere versleutelde data veel veiliger is.

Bescherming van systeembestanden:
– [   ] Voorkom publieke toegang tot readme.html, readme.txxt, wp-config.php, install.php, wp-includes en .htaccess. Deze bestanden kunnen belangrijke informatie over je site weggeven en hebben geen publiek nut nadat WordPress succesvol geïnstalleerd is.

Deactiveer mappen browsen:
– [   ] Voorkomt dat gebruikers een lijst van bestanden in een map kunnen zien wanneer er geen index-bestand aanwezig is.

Filter verdachte querystrings in de URL:
– [   ] Deze zijn vaak tekenen dat iemand probeert toegang tot je site te krijgen.

Filter lange URL-strings:
– [   ] Beperkt het aantal karakters dat kan worden verzonden in de URL. Hackers maken vaak gebruik van lange URLs om te proberen informatie in je database te plaatsen.

Verwijder schrijfpermissies voor bestanden:
– [   ] Voorkomt dat scripts en gebruikers kunnen schrijven naar het wp-config.php bestand en het .htaccess bestand.

Deactiveer PHP in uploads folder, plugins en thema’s:
– [   ] Blokkeert verzoeken aan kwaadwillig geüploadde PHP-bestanden in de uploads map en verzoeken aan PHP-bestanden in de plugins en thema mappen die rechtstreeks kunnen worden uitgebuit.

Verminder Reactie Spam:
– [   ] Deze optie zal reactie-spam verminderen door middel van het weigeren van reacties van bots zonder verwijzer (referrer) of zonder een opgegeven gebruikersagent (user-agent).

Deactiveer bestandsbewerker:
– [   ] Deactiveert de bestandsbewerker voor plugins en thema’s. Hierdoor moeten gebruikers toegang hebben tot het systeem om bestanden aan te passen.

Preventie tegen tabnapping:
– [   ] Pas target=”_blank” links aan om tegen tabnapping te beschermen. Deze functie helpt bezoekers (inclusief ingelogde gebruikers) te beschermen tegen phishing aanvallen geïnitieerd door een gelinkte site.

 

 

Volledige Security Checklist (EN)


##### AUTHENTICATION SYSTEMS (Signup/Signin/2 Factor/Password reset)
– [   ] Use HTTPS everywhere.
– [   ] Store password hashes using `Bcrypt` (no salt necessary – `Bcrypt` does it for you).
– [   ] Destroy the session identifier after `logout`.
– [   ] Destroy all active sessions on reset password (or offer to).
– [   ] Must have the `state` parameter in OAuth2.
– [   ] No open redirects after successful login or in any other intermediate redirects.
– [   ] When parsing Signup/Login input, sanitize for javascript://, data://, CRLF characters.
– [   ] Set secure, httpOnly cookies.
– [   ] In Mobile `OTP` based mobile verification, do not send the OTP back in the response when `generate OTP` or `Resend OTP` API is called.
– [   ] Limit attempts to `Login`, `Verify OTP`, `Resend OTP` and `generate OTP` APIs for a particular user. Have an exponential backoff set or/and something like a captcha based challenge.
– [   ] Check for randomness of reset password token in the emailed link or SMS.
– [   ] Set an expiration on the reset password token for a reasonable period.
– [   ] Expire the reset token after it has been successfully used.

##### DATABASE
– [   ] Use encryption for data identifying users and sensitive data like access tokens, email addresses or billing details.
– [   ] If your database supports low cost encryption at rest (like [AWS Aurora](https://aws.amazon.com/about-aws/whats-new/2015/12/amazon-aurora-now-supports-encryption-at-rest/)), then enable that to secure data on disk. Make sure all backups are stored encrypted as well.
– [   ] Use minimal privilege for the database access user account. Don’t use the database root account.
– [   ] Store and distribute secrets using a key store designed for the purpose. Don’t hard code in your applications.
– [   ] Fully prevent SQL injection by only using SQL prepared statements. For example: if using NPM, don’t use npm-mysql, use npm-mysql2 which supports prepared statements.

##### DEVELOPMENT
– [   ] Ensure that all components of your software are scanned for vulnerabilities for every version pushed to production. This means O/S, libraries and packages. This should be automated into the CI-CD process.
– [   ] Secure development systems with equal vigilance to what you use for production systems. Build the software from secured, isolated development systems.

##### AUTHENTICATION
– [   ] Ensure all passwords are hashed using appropriate crypto such as bcrypt. Never write your own crypto and correctly initialize crypto with good random data.
– [   ] Implement simple but adequate password rules that encourage users to have long, random passwords.
– [   ] Use multi-factor authentication for your logins to all your service providers.

##### DENIAL OF SERVICE PROTECTION
– [   ] Make sure that DOS attacks on your APIs won’t cripple your site. At a minimum, have rate limiters on your slower API paths like login and token generation routines. Consider CAPTCHA on front-end APIs to protect back-end services against DOS.
– [   ] Enforce sanity limits on the size and structure of user submitted data and requests.
– [   ] Use [Distributed Denial of Service](https://en.wikipedia.org/wiki/Denial-of-service_attack) (DDOS) mitigation via a global caching proxy service like [CloudFlare](https://www.cloudflare.com/). This can be turned on if you suffer a DDOS attack and otherwise function as your DNS lookup.

##### WEB TRAFFIC
– [   ] Use TLS for the entire site, not just login forms and responses. Never use TLS for just the login form.
– [   ] Cookies must be httpOnly and secure and be scoped by path and domain.
– [   ] Use CSP without allowing unsafe-* backdoors. It is a pain to configure, but worthwhile.
– [   ] Use X-Frame-Option, X-XSS-Protection headers in client responses.
– [   ] Use HSTS responses to force TLS only access. Redirect all HTTP request to HTTPS on the server as backup.
– [   ] Use CSRF tokens in all forms and use the new [SameSite Cookie](https://scotthelme.co.uk/csrf-is-dead/) response header which fixes CSRF once and for all newer browsers.

##### APIs
– [   ] Ensure that no resources are enumerable in your public APIs.
– [   ] Ensure that users are fully authenticated and authorized appropriately when using your APIs.

##### VALIDATION & ENCODING
– [   ] Do client-side input validation for quick user feedback, but never trust it.
– [   ] Validate every last bit of user input following a whitelist approach on the server. Never use untrusted user input in SQL statements or server-side contexts that are being evaluated. Always validate and encode user input before displaying in responses.

##### CLOUD CONFIGURATION
– [   ] Ensure all services have minimum ports open. While security through obscurity is no protection, using non-standard ports will make it a little bit harder for attackers.
– [   ] Host backend database and services on private VPCs that are not visible on any public network. Be very careful when configuring AWS security groups and peering VPCs which can inadvertently make services visible to the public.
– [   ] Isolate logical services in separate VPCs and peer VPCs to provide inter-service communication.
– [   ] Ensure all services only accept data from a minimal set of IP addresses.
– [   ] Restrict outgoing IP and port traffic to minimize APTs and “botification”.
– [   ] Always use AWS IAM roles and not root credentials.
– [   ] Use minimal access privilege for all ops and developer staff.
– [   ] Regularly rotate passwords and access keys according to a schedule.

##### USER DATA & AUTHORIZATION
– [   ] Any resource access like, `my cart`, `my history` should check the logged in user’s ownership of the resource using session id.
– [   ] Serially iterable resource id should be avoided. Use `/me/orders` instead of `/user/37153/orders`. This acts as a sanity check in case you forgot to check for authorization token.
– [   ] `Edit email/phone number` feature should be accompanied by a verification email to the owner of the account.
– [   ] Any upload feature should sanitize the filename provided by the user. Also, for generally reasons apart from security, upload to something like S3 (and post-process using lambda) and not your own server capable of executing code.
– [   ] `Profile photo upload` feature should sanitize all the `EXIF` tags also if not required.
– [   ] For user ids and other ids, use [RFC compliant ](http://www.ietf.org/rfc/rfc4122.txt) `UUID` instead of integers. You can find an implementation for this for your language on Github.
– [   ] JWT are awesome. Use them if required for your single page app/APIs.

##### ANDROID / IOS APP
– [   ] `salt` from payment gateways should not be hardcoded.
– [   ] `secret` / `auth token` from 3rd party SDK’s should not be hardcoded.
– [   ] API calls intended to be done `server to server` should not be done from the app.
– [   ] In Android, all the granted [permissions](https://developer.android.com/guide/topics/security/permissions.html) should be carefully evaluated.
– [   ] On iOS, store sensitive information (authentication tokens, API keys, etc.) in the system keychain. Do __not__ store this kind of information in the user defaults.
– [   ] [Certificate pinning](https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning) is highly recommended.

##### SECURITY HEADERS & CONFIGURATIONS
– [   ] `Add` [CSP](https://en.wikipedia.org/wiki/Content_Security_Policy) header to mitigate XSS and data injection attacks. This is important.
– [   ] `Add` [CSRF](https://en.wikipedia.org/wiki/Cross-site_request_forgery) header to prevent cross site request forgery. Also add [SameSite](https://tools.ietf.org/html/draft-ietf-httpbis-cookie-same-site-00) attributes on cookies.
– [   ] `Add` [HSTS](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security) header to prevent SSL stripping attack.
– [   ] `Add` your domain to the [HSTS Preload List](https://hstspreload.org/)
– [   ] `Add` [X-Frame-Options](https://en.wikipedia.org/wiki/Clickjacking#X-Frame-Options) to protect against Clickjacking.
– [   ] `Add` [X-XSS-Protection](https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#X-XSS-Protection) header to mitigate XSS attacks.
– [   ] Update DNS records to add [SPF](https://en.wikipedia.org/wiki/Sender_Policy_Framework) record to mitigate spam and phishing attacks.
– [   ] Add [subresource integrity checks](https://en.wikipedia.org/wiki/Subresource_Integrity) if loading your JavaScript libraries from a third party CDN. For extra security, add the [require-sri-for](https://w3c.github.io/webappsec-subresource-integrity/#parse-require-sri-for) CSP-directive so you don’t load resources that don’t have an SRI sat.
– [   ] Use random CSRF tokens and expose business logic APIs as HTTP POST requests. Do not expose CSRF tokens over HTTP for example in an initial request upgrade phase.
– [   ] Do not use critical data or tokens in GET request parameters. Exposure of server logs or a machine/stack processing them would expose user data in turn.

##### SANITIZATION OF INPUT
– [   ] `Sanitize` all user inputs or any input parameters exposed to user to prevent [XSS](https://en.wikipedia.org/wiki/Cross-site_scripting).
– [   ] Always use parameterized queries to prevent [SQL Injection](https://en.wikipedia.org/wiki/SQL_injection).
– [   ] Sanitize user input if using it directly for functionalities like CSV import.
– [   ] `Sanitize` user input for special cases like robots.txt as profile names in case you are using a url pattern like coolcorp.io/username.
– [   ] Do not hand code or build JSON by string concatenation ever, no matter how small the object is. Use your language defined libraries or framework.
– [   ] Sanitize inputs that take some sort of URLs to prevent [SSRF](https://docs.google.com/document/d/1v1TkWZtrhzRLy0bYXBcdLUedXGb9njTNIJXa3u9akHM/edit#heading=h.t4tsk5ixehdd).
– [   ] Sanitize Outputs before displaying to users.

##### OPERATIONS
– [   ] Power off unused services and servers. The most secure server is one that is powered down.
– [   ] Use a decent provisioning script to create VMs in the cloud.
– [   ] Check for machines with unwanted publicly `open ports`.
– [   ] Check for no/default passwords for `databases` especially MongoDB & Redis.
– [   ] Use SSH to access your machines; do not setup a password, use SSH key-based authentication instead.
– [   ] Install updates timely to act upon zero day vulnerabilities like Heartbleed, Shellshock.
– [   ] Modify server config to use TLS 1.2 for HTTPS and disable all other schemes.
– [   ] Do not leave the DEBUG mode on. In some frameworks, DEBUG mode can give access full-fledged REPL or shells or expose critical data in error messages stacktraces.
– [   ] Be prepared for bad actors & DDOS – use a hosting service that has DDOS mitigation.
– [   ] Set up monitoring for your systems, and log stuff (use [New Relic](https://newrelic.com/) or something like that).
– [   ] If developing for enterprise customers, adhere to compliance requirements. If AWS S3, consider using the feature to [encrypt data](http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingServerSideEncryption.html). If using AWS EC2, consider using the feature to use encrypted volumes (even boot volumes can be encrypted now).

##### INFRASTRUCTURE
– [   ] Ensure you can do upgrades without downtime. Ensure you can quickly update software in a fully automated manner.
– [   ] Create all infrastructure using a tool such as Terraform, and not via the cloud console. Infrastructure should be defined as “code” and be able to be recreated at the push of a button. Have zero tolerance for any resource created in the cloud by hand — Terraform can then audit your configuration.
– [   ] Use centralized logging for all services. You should never need SSH to access or retrieve logs.
– [   ] Don’t SSH into services except for one-off diagnosis. Using SSH regularly, typically means you have not automated an important task.
– [   ] Don’t keep port 22 open on any AWS service groups on a permanent basis. Instead consider allowing only authorized IPs to SSH on the box.
– [   ] Create [immutable hosts](http://chadfowler.com/2013/06/23/immutable-deployments.html) instead of long-lived servers that you patch and upgrade. (See [Immutable Infrastructure Can Be More Secure](https://simplesecurity.sensedeep.com/immutable-infrastructure-can-be-dramatically-more-secure-238f297eca49)).
– [   ] Use an [Intrusion Detection System](https://en.wikipedia.org/wiki/Intrusion_detection_system) like [SenseDeep](https://www.sensedeep.com/) or service to minimize [APTs](https://en.wikipedia.org/wiki/Advanced_persistent_threat).

##### TESTING
– [   ] Audit your design and implementation.
– [   ] Do penetration testing — hack yourself, but also have someone other than you pen testing as well.

##### PEOPLE
– [   ] Set up an email (e.g. security@coolcorp.io) and a page for security researchers to report vulnerabilities.
– [   ] Depending on what you are making, limit access to your user databases.
– [   ] Be polite to bug reporters.
– [   ] Have your code review done by a fellow developer from a secure coding perspective. (More eyes)
– [   ] In case of a hack or data breach, check previous logs for data access, ask people to change passwords. You might require an audit by external agencies depending on where you are incorporated.
– [   ] Set up [Netflix’s Scumblr](https://github.com/Netflix/Scumblr) to hear about talks about your organization on social platforms and Google search.