Security Best Practices

Synapse places a heavy emphasis on adherence to security and compliance standards. Every Synapse customer gets a free security audit, as well as a code review and a compliance review.

This guide aims to outline our security processes and some best practices that will help keep your platform secure. Check out our list of handy open source tools at the end of this post for guidance on implementing security best practices and greatly lessening the burdens associated with adequate security.

Security is a broad topic. However, in the case of web applications and for the sake of brevity, we break it down into three main categories:

1. Client-Side Security
2. Security in Transit
3. Backend Security

Client-Side Security

Client-side security mostly depends on your user data validation process. The first rule of security is "never trust user data." The second rule is: "Always remember the first rule". OWASP is an open source community of security researchers who periodically publish on the Top 10 web list of security issues. Most of these top issues can be avoided by validating user data before sending it to the server.

Cross-site Scripting (XSS) is a bug that lets an attacker execute random Javascript on your site. In the worst case scenario, the attacker can grab cookies of other users and take over a user’s account. XSS can be avoided by validating user’s input for Javascript. A good way to avoid this risk altogether is to not include Javascript from other sites, wherever possible.

Cross-site request forgery (CSRF) tricks the server into believing that a malignant request is from the user itself, allowing the attacker to change the victim/user’s settings, transfer money out of the user’s account, etc. CSRF can be avoided by validating the “state-changing” requests with a random token and validating the random token on the server side.

SQL injection (SQLi) is the worst nightmare possible for a development team. It occurs when an attacker is able to execute SQL queries allowing the attacker to dump databases, delete users, grab passwords and even bypass authentication. SQLi occurs when developers don’t validate user input for SQL queries.

There are many other examples of security issues that can occur simply as a result of not validating a user’s input, which brings us back to the first rule of security: “Never trust user data”. Validate everything that comes from users and take care of a user’s cookies to make sure the same cookies can’t be reused after the user has logged out.

Security in Transit

Security in transit is about securing your data in the process of its transmission from the user’s browser to the server. Man-in-the-middle is a common attack where the attacker intercepts the user requests/data over an insecure channel, thus gaining access to the user’s sensitive information, as well as the ability to change said information and other permissions.

Especially in the finance industry, securing user data over a transmission channel is as important as client-side and backend security. As a bare minimum, the use of HTTPs (secure version of HTTP) is recommended. It uses TLS (earlier SSL) protocol to encrypt data and allows a user to verify they are talking to the correct server. A certificate from a certificate authority (CA) is required to use HTTPs. There are many CAs, such as, Digicert; Let’s Encrypt; and Namecheap. Alternatively, you can ask your domain/server service provider to help you get a certificate. Once you get the certificate, configure it on your server following the installation guide on the service provider’s website. Note: Avoid certificates that use SHA-1 as it is depreciated.

If you’re using Synapse, make sure that you securely maintain your client_id, client_secret, oauth_key, and refresh_token (i.e. that none of them are leaked anywhere). Don’t use session IDs in URL. Even if you are using HTTPS, URLs with session IDs can get leaked to third party services in the request header.

🚧

Webhooks

When using webhooks, make sure it’s using TLS and wherever possible don’t share user data over webhooks.

Backend Security

First step you can take with your backend security is to give less information about your infrastructure. Use custom 404/403 page, don’t leak server/PHP version in your response as this can be used by an attacker to gather information about your previous infrastructure versions. Second step would be to protect your “server sudo”; not everyone in your organization needs access to everything. Harden your SSH, use public/private key based logins.

Please update your application often, for example, disable SSL v3 support for Apache SSL. Always monitor your logs, backup your data, and don’t use outdated encryption methods (such as MD5). There is no need to store any data that can be retrieved via APIs. Content delivery network (CDN), IDS (Intrusion detection system), IPS (Intrusion prevention system), Firewall, and load balancers are all must-haves.

We can sum up backend security with these quick pointers; use updated software, don’t leak information, close ports that are not in use, always have a backup, check default configurations of softwares, make sure there are layers of protection like firewall, load balancer, CDN, IDS, IPS before server, and finally, always monitor your logs.

Open-Source Tools

There are many open-source tools that you can use to implement some of the best practices mentioned in this guide.

• Firewall is the first layer of defense for your server, if you’re on Ubuntu server you can use Uncomplicated Firewall (UFW). It is a basic firewall that uses basic sets of rules, this is fine for a website with average traffic.

• ModSecurity is an open source web application firewall, it provides real-time web application monitoring, logging and access control.

• Sysctl can be used for network hardening. It prevents source routing and logs malformed IP and takes care of TCP/IP stack.

• Mod_evasive is an Apache module, it helps in protection against DoS, DDoS and brute force against Apache web server.

• Nmap is a port scanning tool, it helps find open ports that are not being used by the sever.

• DenyHosts is a Python program that prevents SSH server against brute force and dictionary based attacks.

• Fail2Ban scans log files and bans IPs with malicious actions such as too many login attempts or seeking for exploits. Fail2ban can be used to update firewall rules and it can be used for various services like Apache, SSH etc.

• PSAD is an intrusion detection tool for Linux that analyzes iptables log messages to detect port scans and other malicious activity.

• Rkhunter checks your server against rootkit, which is a malicious masked application that enables access to your server including the protected parts. Also, Chkrootkit can be used for the same purpose.

• Logwatch is a log parser than can be used to track an application’s log and related issues to the application. It is available as an Ubuntu/CentOS/RHEL module.

• Tiger is an intrusion detection tool that also helps in a security audit. Available for free to all members of the Unix family.

Other than these, if you are interested in testing your application in SDLC process, you can integrate OWASP ZAP with Selenium. This will automate the security testing process to a certain extent, more details on this here.

OWASP ZAP can also be used as a stand-alone application to scan your web platform for OWASP Top-10 and other issues.

There is so much more to security beyond these common best practices and guidelines. We recommend you keep your security updated and stay informed on recent exploits and security breaches.

Security as a Service

At Synapse we provide security audits and compliance support to all our customers. From time-to-time we also write security posts, which can be found on our blog.

If you have any questions regarding our security or you feel your Synapse account has been compromised, please contact our support team or email us at [email protected].

Security Researchers

At Synapse we believe security is a team effort. If you believe you have found any security issues with our API or Dashboard, please reach out to us at [email protected]. We’ll invite you to our private bug bounty and acknowledge your efforts.