{"__v":0,"_id":"5915e63e7c2c552d008b856a","category":{"project":"54e405191e51932d006abc39","version":"55fa37c88065a10d004e5bb6","_id":"5915e54f7c2c552d008b8549","__v":0,"sync":{"url":"","isSync":false},"reference":false,"createdAt":"2017-05-12T16:39:43.277Z","from_sync":false,"order":1,"slug":"guides","title":"Guides"},"parentDoc":null,"project":"54e405191e51932d006abc39","user":"5820c42f6256350f00fc6e31","version":{"__v":8,"_id":"55fa37c88065a10d004e5bb6","project":"54e405191e51932d006abc39","createdAt":"2015-09-17T03:47:20.956Z","releaseDate":"2015-09-17T03:47:20.956Z","categories":["55fa37ca8065a10d004e5bb7","55fa37ca8065a10d004e5bb8","55fa37ca8065a10d004e5bb9","55fa37ca8065a10d004e5bba","55fca6bf34ae7c0d00ab8ea0","55ff80fd9e7ccf0d000a1d93","560220af7435de0d00fabd0d","56107f21bb9d920d00303e70","563e184077681a0d00d96a02","56fafc6596ec7e0e002ac85f","5915e54f7c2c552d008b8549"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"REST V3","version_clean":"3.1.0","version":"3.1"},"updates":[],"next":{"pages":[],"description":""},"createdAt":"2017-05-12T16:43:42.340Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":999,"body":"If you’re a Synapse user you probably already know the emphasis we place on security and compliance. For those who don’t know, every Synapse customer gets a free security audit, in addition to a code review and a compliance review. \n\nThis guide aims to teach you about our security processes and some best practices that will help keep your platform secure.  Be sure to check out our list of handy open source tools at the end of this post that can lessen the security burden immensely.\n\nSecurity is a broad topic, in the case of web applications and for the sake of simplicity however, we can break it down into 3 main categories:\n1. [Client-side security](#section-client-side-security)\n2. [Security in transition](#section-security-in-transition)\n3. [Backend security](#section-backend-security)\n\n## Client-side Security\n\nClient-side security mostly depends on your process of validating user’s data. I’ve said this time and again, 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 publish a Top 10 security issues on web list periodically, most of these top issues can be avoided if we validate user’s data before sending it server. \n\nCross site Scripting (XSS) is a bug that lets 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.\n\nCross-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.\n\nSQL injection(SQLi) is the worst nightmare possible for a development team, and 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 these queries. \n\nThere 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 user’s cookies to make sure the same cookies can’t be reused after the user has logged out.\n\n## Security in Transition\n\nSecurity in transition 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.\n\nEspecially 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 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, Namecheap or 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.\n\nIf you’re using Synapse integration, make sure client_id, client_secret, oauth_key, refresh_token is not 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. \n[block:callout]\n{\n  \"type\": \"warning\",\n  \"title\": \"Webhooks\",\n  \"body\": \"When using webhooks, make sure it’s using TLS and wherever possible don’t share user data over webhooks.\"\n}\n[/block]\n## Backend Security\n\nFirst thing you can do 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.\n\nMake sure you are not using old application from 90s, update your application more 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, load balancers are all must haves.     \n\nWe 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.\n\n## Open source tools\n\nThere are many open source tools that you can use to implement some of the best practices mentioned in this guide.  \n\n* Firewall is the first layer of defense for your server, if you’re on Ubuntu server you can use [Uncomplicated Firewall](https://help.ubuntu.com/community/UFW) (UFW). It is a basic firewall that uses basic sets of rule that would be fine for a website with average traffic.\n\n* [ModSecurity](https://modsecurity.org/) is an open source web application firewall, it provides real-time web application monitoring, logging and access control.\n\n* [Sysctl](https://wiki.archlinux.org/index.php/sysctl#Security) can be used for network hardening. It prevents source routing and logs malformed IP and takes care of TCP/IP stack.\n\n* Mod_evasive is an Apache module, it helps in protection against DoS, DDoS and brute force against Apache web server. \n\n* [Nmap](https://nmap.org/) is a port scanning tool, it helps in finding open ports that are not being used by the sever.\n\n* [DenyHosts](http://denyhosts.sourceforge.net/) is a python program that prevents SSH server against brute force and dictionary based attacks.\n\n* [Fail2Ban](https://www.fail2ban.org/wiki/index.php/Main_Page) scans log file and bans IPs with malicious actions like - too many login attempts, seeking for exploits. Fail2ban can be used to update firewall rules and it can be used for various services like Apache, SSH etc.\n\n* [PSAD](http://cipherdyne.org/psad/) is an intrusion detection tool for Linux that analyzes iptables log messages to detect port scans and other malicious activity.\n\n* [Rkhunter](http://rkhunter.sourceforge.net/) checks your server against rootkit, which is a malicious masked application that enable access to your server including the protected parts! Also, [Chkrootkit](http://www.chkrootkit.org/) can be used for same purpose.\n\n* [Logwatch](https://sourceforge.net/projects/logwatch/files/) is a log parser than can be used to track application’s log and related issues to the application. It is available as an Ubuntu/CentOS/RHEL module.\n\n* [Tiger](http://www.nongnu.org/tiger/) is an intrusion detection tool that also helps in security audit. Available for free to all members of Unix family.   \n\nOther 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](https://www.youtube.com/watch?v=aVFZFi_6B9g). \n\n[OWASP ZAP](https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project) can also be used as a standalone application to scan your web platform for OWASP Top-10 and other issues.\n\nThere is so much more to security beyond these common best practices and guidelines. Try to stay a few steps ahead of attacker by staying updated on security. Read up on recent exploits and breaches, read everything.\n\n## Security as a Service\n\nAt Synapse we provide security audits and compliance support to all our customers. You can learn more about this at our [product page](https://synapsepay.com/security). From time to time we also write security posts, so you can read those as well on our [blog](https://blog.synapsepay.com/).\n\nIf you have any questions regarding our security or you feel like your Synapse account has been compromised, please contact our [support](https://help.synapsepay.com/hc/en-us/requests/new) team or email us at support:::at:::synapsepay.com.\n\nFor security researchers:\nWe at Synapse 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 support+security@synapsepay.com. We’ll invite you to our private bug bounty and acknowledge your efforts.","excerpt":"","slug":"synapse-security","type":"basic","title":"Security Best Practices"}

Security Best Practices


If you’re a Synapse user you probably already know the emphasis we place on security and compliance. For those who don’t know, every Synapse customer gets a free security audit, in addition to a code review and a compliance review. This guide aims to teach you about our security processes and some best practices that will help keep your platform secure. Be sure to check out our list of handy open source tools at the end of this post that can lessen the security burden immensely. Security is a broad topic, in the case of web applications and for the sake of simplicity however, we can break it down into 3 main categories: 1. [Client-side security](#section-client-side-security) 2. [Security in transition](#section-security-in-transition) 3. [Backend security](#section-backend-security) ## Client-side Security Client-side security mostly depends on your process of validating user’s data. I’ve said this time and again, 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 publish a Top 10 security issues on web list periodically, most of these top issues can be avoided if we validate user’s data before sending it server. Cross site Scripting (XSS) is a bug that lets 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, and 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 these 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 user’s cookies to make sure the same cookies can’t be reused after the user has logged out. ## Security in Transition Security in transition 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 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, Namecheap or 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 integration, make sure client_id, client_secret, oauth_key, refresh_token is not 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. [block:callout] { "type": "warning", "title": "Webhooks", "body": "When using webhooks, make sure it’s using TLS and wherever possible don’t share user data over webhooks." } [/block] ## Backend Security First thing you can do 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. Make sure you are not using old application from 90s, update your application more 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, 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](https://help.ubuntu.com/community/UFW) (UFW). It is a basic firewall that uses basic sets of rule that would be fine for a website with average traffic. * [ModSecurity](https://modsecurity.org/) is an open source web application firewall, it provides real-time web application monitoring, logging and access control. * [Sysctl](https://wiki.archlinux.org/index.php/sysctl#Security) 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](https://nmap.org/) is a port scanning tool, it helps in finding open ports that are not being used by the sever. * [DenyHosts](http://denyhosts.sourceforge.net/) is a python program that prevents SSH server against brute force and dictionary based attacks. * [Fail2Ban](https://www.fail2ban.org/wiki/index.php/Main_Page) scans log file and bans IPs with malicious actions like - too many login attempts, seeking for exploits. Fail2ban can be used to update firewall rules and it can be used for various services like Apache, SSH etc. * [PSAD](http://cipherdyne.org/psad/) is an intrusion detection tool for Linux that analyzes iptables log messages to detect port scans and other malicious activity. * [Rkhunter](http://rkhunter.sourceforge.net/) checks your server against rootkit, which is a malicious masked application that enable access to your server including the protected parts! Also, [Chkrootkit](http://www.chkrootkit.org/) can be used for same purpose. * [Logwatch](https://sourceforge.net/projects/logwatch/files/) is a log parser than can be used to track application’s log and related issues to the application. It is available as an Ubuntu/CentOS/RHEL module. * [Tiger](http://www.nongnu.org/tiger/) is an intrusion detection tool that also helps in security audit. Available for free to all members of 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](https://www.youtube.com/watch?v=aVFZFi_6B9g). [OWASP ZAP](https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project) can also be used as a standalone 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. Try to stay a few steps ahead of attacker by staying updated on security. Read up on recent exploits and breaches, read everything. ## Security as a Service At Synapse we provide security audits and compliance support to all our customers. You can learn more about this at our [product page](https://synapsepay.com/security). From time to time we also write security posts, so you can read those as well on our [blog](https://blog.synapsepay.com/). If you have any questions regarding our security or you feel like your Synapse account has been compromised, please contact our [support](https://help.synapsepay.com/hc/en-us/requests/new) team or email us at support@synapsepay.com. For security researchers: We at Synapse 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 support+security@synapsepay.com. We’ll invite you to our private bug bounty and acknowledge your efforts.