Tools and technologies for a highly secure web application

We plan to create a web application that should be very secure, because a lot of money and reputation are at risk. Therefore, I am looking for tools and technologies that help in this endeavor. Tools and technologies should help prevent things like SQL injection, cross-site scripting vulnerabilities, remote code execution, etc.

Our team has strong knowledge of these vulnerabilities. But every developer makes mistakes, and a simple mistake should not lead to a security vulnerability. They should be prevented or detected using the web application infrastructure, application server, programming language, security library, code analyzer, etc.

A simple example: if you embed data in HTML, you need to escape it so that it displays correctly and is not used for script injection. Some web application platforms place this burden on developers. If they forget to escape in one place, they have a security problem. A good tool will not just do auto-escaping, it will even prevent developers from doing this forcibly.

I am not looking for recommendations regarding a firewall (we have a good one), simplifying the operating system (this part of the plan), using encrypted communication (this will be the only option), and secure authentication (a hardware token). Rather, recommendations should be centered around the application server and the web application being created.

We also fully understand that writing secure software is more than just technology: people with knowledge, leadership attention, time and money, and software quality processes are involved. So far this is not a problem, not the focus of this issue.

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

So, what tools and technologies or their combinations can you recommend to us?

+6
java security web-applications
source share
6 answers

Background

The vulnerabilities you mentioned are related to confusing data with control (or code, if you want). They arise in practice, because many programming languages โ€‹โ€‹and APIs are not able to encode the semantics of domain languages โ€‹โ€‹such as SQL, HTML, and the system shell. For example, almost all XSS vulnerabilities arise because the programmer prints a non-sanitized string, and the programming language or API does not contain enough information to detect that the string was sent by the user and should have its own control characters. Fortunately, there are language extensions and APIs that separate data from management and can eliminate almost all of these attacks.

SQL Injection

  • Prepared JDBC statements A prepared statement for Java is de facto for accessing a DBMS at the SQL level. You write SQL queries with variables, and then specify the values โ€‹โ€‹of these variables and their types, effectively providing the DBMS with enough information to avoid your data, leaving only the query structure (control).
  • Request creators. Instead of specifying a query as a string, you can represent it as a sequence of method calls that gradually create an object as a builder template. You can think of it as creating the AST manually, and then serializing it as a query string. There is an article from Roberson and Vigna that illustrates some examples in Haskell.
  • LINQ This applies to .NET. Queries are actually part of the language, so the analyzer can distinguish between query keywords and data. Once again, this allows the language to safely avoid only data. Due to my lack of experience with LINQ, I cannot say much more, but presumably the data values โ€‹โ€‹are wrapped in SqlParameter objects, which subsequently escaped.
  • ORM structures. A level higher than SQL injection, ORM frameworks are aimed at abstracting most DBMS parts, including the queries themselves. They can use prepared statements behind the scenes or even expose an API like prepared ones for more direct access to a database (for example, Hibernate SQLQuery ).

Cross Site Scripting (XSS)

Many of the methods to prevent XSS attacks are similar in spirit to SQL injection protection. Only this time, the goal is a web browser, not a database. In any case, we do not want the data to be mistakenly interpreted as control.

  • Templates. . Most popular template languages โ€‹โ€‹seem to be for PHP, Python, or Ruby. However, there are several for Java and for .NET . Typically, a template consists of HTML and data placeholders. Then you transfer your data to the template engine, this eludes all of this, and then displays the template with replaceable placeholders on disinfected data.
  • The creators of the DOM tree. . Like SQL query builders, you can create 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. Of course, the standard DOM API, unfortunately, is too verbose to make this approach acceptable.
  • XML literals. Like LINQ, XML literals are a native part of the language that allows the parser to distinguish markup from data. Although neither Java nor C # supports XML literals, Scala also does VB9 . Facebook has an open source PHP extension called XHP , which also provides several software development benefits, including reuse of components and the ability to specify model content for custom tags.
  • Heuristics and discovery. . This is not protection against reliable protection, but some systems consider HTML output and assume that a malicious script is embedded. However, as people discovered with IE8, this may include attacks .
  • HTTP cookies only. This is not XSS protection, but it can prevent many attacks. When your server sets a cookie, it can mark it as "HTTP only" , which means that supported browsers will not allow JavaScript to access the cookie page. Thus, even if an attacker can embed malicious scripts on your site, they will not be able to steal your user cookies if they have a fairly modern browser (even IE6 + counts!).

Remote code execution

I have nothing to say on this topic, but try to minimize system() -like calls as much as possible. If you need to make calls to other binary files, use good security methods, for example, using a white list where possible, and, if necessary, use well-tested sanitation functions. Some APIs, such as Python Popen , do a good job of ensuring that arguments are not treated as shell control characters. Finally, using Java and C #, buffer overflow exploits are highly unlikely. This is not an official guarantee, but companies with billions of dollars all the time work on Java servers.

Best practics

Ultimately, you should consider using APIs or language functions designed for this task, whether it be creating an SQL query or creating an HTML page. These languages โ€‹โ€‹and APIs not only increase your confidence in security, but also often help programming. Compared to the old tactics of combining string strings, we now have LINQ and XML literals that may make the code easier to write, easier to read, and easier to check. I am a fan of language enhancements and APIs that improve code quality and programmer productivity!

+13
source share

My best advice is to require pair programming or code reviews for all the code written. It's easy as one developer to skip something or forget about security measures, but if that happens, you should pick it up when viewing the code, especially when the reviewer knows that security is critical to the application.

In terms of tools, check out Google Skipfish . This allows you to run a full suite of tests against the application, telling you where there may be things you need.

+4
source share

No tests can detect holes in the loops better than the person who is on the development team.

Risks are in standard products.

For example, most attacks come against open source systems, and standard products as part of the simple assumption that if you use WordPress and if any php script can cause SQL injection, then, unfortunately, your site may be attacked easy.

Specially designed software is safe until ...

  • Directory browsing is disabled because no one should crawl your pages unless you intend to
  • Open source or standard tools, such as SQL Server, WordPress or any such third-party tool, should not remain open in the end client
  • Implement the DTO template, that is, use data transfer objects, consider the possibility of data transfer, but not the logic
  • Using token protection instead of UI Security, just pinning a ui element to a user is never safe

The largest of all, your business logic (even the smallest, like login and signup), should and should only be executed in controlled rooms.

Everything that is not in your premises, in any web browser, any mobile client, considers it a dangerous threat, and then a code.

Team warfare

Separate your teams and tell your teams about attacking and hacking or hacking another command code, as part of testing, always remember that someone who knows your business logic, access points is more dangerous than any of the existing viruses or trojans or network intruders.

+1
source share

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

In particular, if you want to create a secure web application, you will need to adopt a secure development process, such as OWASP ASVS or Microsoft SDL

This blog post explains more about why security is more of a process problem than problems with tools or training.

+1
source share

It is better to test your web application with people outside the office, for example, trusted testers for Google, for this there are security consultants. They can test with ideas out of the box and come up with a lot of leaks and someday suggest u good implementAtion.

0
source share

You can use the Websecirify tool to test security for a web application. http://www.websecurify.com/

This tool can detect various security vulnerabilities. These include:

  • Cross Site Scripting (XSS)
  • Cross Site Request Forgery (CSRF)
  • Directory List
  • System Path Uncover Vulnerabilities
  • SQl injection
  • Cancel URL Redirection and
  • Cookie problem disclosure and
  • many popular and lesser-known vulnerabilities.
0
source share

All Articles