SQL Injection vulnerabilities are one of the most common attack vectors into web applications. In SQL Injection attacks, hackers embed SQL (Structured Query Language) commands into web form and URL inputs, exploiting web applications that pass un-filtered values to a database. Singlebrook defends against these attacks in our applications by ensuring that all database inputs are parameterized (or "bound"), which cleanly separates SQL commands and parameters. Read more at Wikipedia.
XSS vulnerabilities are created when web applications display user-entered content without filtering it for dangerous content. These sophisticated attacks usually involve passing malicious Javascript to a page via a web form or in the URL. The unfiltered, malicious code is then included in the page by the naive application. Singlebrook prevents these attacks from happening by filtering (or "escaping") all user-entered content before displaying it on the page. Read more at Wikipedia.
CSRF attacks are when a malicious individual constructs a web form or URL that leads to a desired action taking place in the target application. This action is something that the attacker doesn't have access to, but they can get a privileged user to execute the action for them if they can get that user to submit their specially-constructed form or visit their hand-crafted URL. We shut these attacks down in our applications by putting user-specific, one-time-use request tokens in our forms. Without a valid token, generated by a form in our application, a data-changing request will not be honored. Read more at Wikipedia.
Servers run a minimal number of services, providing only required functionality. Services do not allow external communication if it is not necessary.
Firewalls control access to servers and services. Servers have strict individual firewall configurations that provide access only to externally-exposed services. Even if a service is enabled inadvertently, the firewall will prevent it from being accessible unless an administrator explicitly grants access to it. In addition, only authorized external systems are allowed to communicate with externally-exposed services.
Standard Administrative accounts are disabled or have limited access. Developers use their own accounts, allowing us to disable an individual's account if necessary. We use two-factor public-key authentication instead of password authentication, foiling keystroke loggers and mitigating the risk of account disclosure due to lost laptops or stolen workstations.
We use strong WPA2 encryption on our wireless networks coupled with MAC-address-based access control lists.
When using an external network, such as a public wireless hotspot, we encrypt our communications using SSL and TLS technologies. This prevents our communications from being intercepted in transit.