Tools and technologies for a highly secure web application

Question

We're planning to build a web application that needs to be highly secure because a lot of money and reputation is at risk. Therefore I'm looking for tools and technologies that help in that endeavor. The tools and technologies should help prevent things like SQL injection, cross-site scripting vulnerabilities, remote code execution etc.

Our team has a solid knowledge about such vulnerabilities. But every developer makes mistakes, and a simple mistake shouldn't lead to a security vulnerability. They should be prevented or detected by web application framework, application server, programming language, security library, code analyzer etc.

A simple example: If you insert data into HTML, it needs to be escaped so it's properly displayed and not misused for injecting scripts. Some web application frameworks put this burden on the developers. If they forget the escaping in one place, they've got a security problem. A good tool wouldn't just do the escaping automatically, it would even prevent the developers from doing it forcefully.

I'm not looking for recommendations regarding the firewall (we have a good one), hardening the operating system (that's part of the plan), use of encrypted communication (it will be the only option) and secure authentication (a hardware token will be used). Rather, the recommendations should center around the application server and the web application software to be built.

We also fully understand that writing secure software is more than just technology: It involves knowledgable people, management attention, time and money and software quality processes. So far, this is not the problem and not the focus of this question.

I should mention that we have a certain bias towards Java and .NET.

So what tools and technologies or combinations thereof can you recommend us?

Answer 1

My best advice would be to require pair programming or code reviews for all code written. It is easy as a single developer to miss something or forget a security measure - but if that happens, it should get picked up at the code review, especially when the reviewer is aware that security is mission-critical for the application.

In terms of tools, checkout Google Skipfish. It allows you to run a comprehensive suite of tests against the application, telling you where there might be things that need your attention.

Answer 2

Background

The vulnerabilities you mentioned all stem from a confusion of data with control (or code, if you'd prefer). They arise in practice because many programming languages and APIs aren't equipped to encode the semantics of domain-specific languages like SQL, HTML, and the system shell. For example, nearly all XSS vulnerabilities occur because a programmer prints out an un-sanitized string and the programming language or API doesn't have enough information to detect that the string was user-submitted and should have had its control characters escaped. Fortunately, there are language extensions and APIs that do separate data from control and can eliminate nearly all of these attacks.

SQL Injections

• Prepared statements. The JDBC prepared statement implementation for Java is the de facto standard for accessing DBMSes at the SQL level. You write SQL queries with variables, and then specify the values of those variables and their types, effectively giving the DBMS enough information to escape your data while leaving your query structure (the control) alone.
• Query builders. Instead of specifying a query as a string, you can represent it as a sequence of method calls that gradually build up an object, in the fashion of the builder pattern. You might think of it as building up an AST by hand and then serializing it as a query string. There is a paper by Robertson and Vigna that illustrates some examples in Haskell.
• LINQ. This is specific to .NET. Queries are effectively part of the language, so the parser can distinguish between query keywords and data. Once again, this allows the language to safely escape only the data. Due to my lack of experience with LINQ I can't say much more, but presumably data values are wrapped in SqlParameter objects that are subsequently escaped.
• ORM frameworks. A level above SQL injections, ORM frameworks aim to abstract away most of the DBMS details, including the queries themselves. They may use prepared statements behind the scenes, or even expose a prepared-statement-like API for more direct access to the database (for example, Hibernate's SQLQuery).

Cross-site Scripting (XSS)

Many of the techniques for preventing XSS attacks are similar in spirit to defenses against SQL injections. Only this time, the target is the web browser instead of the database. Either way, we don't want data to be mistakenly interpreted as control.

• Templates. Most of the popular templating languages seem to be targeted at PHP, Python, or Ruby. However, there are a few out there for Java and for .NET. A template usually consists of HTML and placeholders for data to go. You then pass your data into the template engine, it escapes it all, and then it renders the template with the placeholders replaced with the sanitized data.
• DOM tree builders. Similar to the SQL-query builders, you might construct a page using a DOM-like API to create new elements and text nodes, and finally serialize them as an HTML string at the end. Debatably, the standard DOM API is unfortunately too verbose for this approach to be palatable.
• XML literals. Like LINQ, XML literals are a native part of a language that allows the parser to distinguish markup from data. While neither Java nor C# support XML literals, Scala does and so does VB9. Facebook has an open-source PHP extension called XHP that provides several software engineering benefits as well, including component reuse and being able to specify content models for custom tags.
• Heuristics and detection. This isn't a sure-fire defense, but some systems examine the HTML output and guess if malicious script is embedded. However, as people discovered with IE8, this can enable attacks.
• HTTP-only cookies. This is not a defense against XSS, but it can prevent quite a few attacks. When your server sets a cookie, it can mark it as HTTP-only, meaning that supported browsers won't let JavaScript on a page access that cookie. Thus, even if an attacker is able to embed malicious script on your site, they won't be able to steal your user's cookies, provided they have a reasonably modern browser (even IE6+ counts!).

Remote Code Execution

I don't have much to say on this topic, but try to minimize system()-like calls as much as possible. If you have to make calls to other binaries, apply good security practices such as using a whitelist where possible and using well-vetted sanitization functions where appropriate. Some APIs, like Python's Popen, do a nice job of ensuring that arguments aren't treated as shell control characters. Finally, with Java and C#, buffer overflow exploits are highly unlikely. It's not a formal guarantee, but billion-dollar companies run Java servers all the time.

Best Practices

Ultimately, you should consider using an API or language features that are designed for the task at hand, whether it is creating a SQL query or building an HTML page. Not only do these languages and APIs increase your confidence with regard to security, but they often facilitate programming as well. Compared with the old-school tactic of concatenating a bunch of strings, we now have LINQ and XML literals that arguably make code easier to write, easier to read, and also easier to verify. I'm a fan of language enhancements and APIs that improve both code quality and programmer productivity!

Answer 3

No tests can detect loop holes better then the person who is in team of development.

Risks are in Standard Products

For example, the majority of attacks comes on open source systems, and standard products as part of simple guess that if you are using WordPress, and if any php script can cause sql injection attack then ofcourse your website can be attacked easily.

Custom developped software is safe as long as...

1. Directory browsing is turned off like no one should be able to crawl your pages unless you intend to
2. Open source, or standard tools like, SQL Server, WordPress or any such third party tool should not be left open on end client
3. Implement DTO pattern, ie use Data Transfer Objects, consider transimitting data, but not the logic
4. Use token security instead of UI Security, just hinding a ui element from the user is never safe

The biggest of all, your business logic (even the smallest one like login and signup), should and only should execute in your controlled premises.

Anything that is not in your premises, any web browser, any mobile client, consider it to be guarenteed danger and then code.

Team War

Divide your teams, and tell teams to attack and bring down or crack other team's code, as part of testing, always remember that the one who knows your business logic, access locations is more dangerous then any of existing viruses or trojans or network attackers.

Answer 4

It is better to test your web application with people outside your office,like trusted testers for google,there are security consultants specifically for this. They may test with out of box ideas and come up with lot of leaks and sometime suggest u good implementAtion.

Answer 5

Security is an aspect of quality, and quality is determined by your process, not by your tools (which serve the process).

Specifically, if you want to build a highly secure web app, you're going to need to adopt a secure development process, like OWASP ASVS or Microsoft SDL

This blog post explains more about why security is more a process issue than a tools or training issue.