IT applications have transformed business over recent decades. As technology has advanced, dumb terminals have been replaced by PCs and mobile devices. As reliance on technology has grown, so have the security concerns. There have been great changes in how applications are architectured and developed, which can have surprising effects on system security.
The earliest business applications ran on mainframes and dumb terminals. The clients were "dumb" in the sense that they didn't do any local processing. They just send key strokes to the mainframe, and display the data returned. Later models allowed colours and rudimentary graphics, but kept the terminal basically dumb.
In this architecture, it is possible for applications to have security vulnerabilities, and this area is not well researched. But there is a feature of this design that tends to discourage vulnerabilities. The only input a client can make is key strokes. Consider an application that presents a list of actions, tells you to "pick 1 - 9", and option 2 is disabled unless you have special permissions. If you pick option 2, the application needs to check your permissions, and failure to do this would normally be picked up in usability testing. There's little scope for an attacker to send something subversive that bypasses the checks and gains unauthorised access to the function.
As technology developed, PCs became more widely used. It's still possibly to use the old mainframe applications with a terminal emulator, and you see these in use even today.
But the benefit of PCs is that they're not dumb - they can do local processing. People wanted applications that took advantage of these new features. For example, to take data from a terminal screen, merge it into a word processor document, and print that locally. This led to the development of applications that are broadly called "fat clients".
One approach for designing fat clients is to communicate with the original mainframe terminal application. The software has a terminal emulator embedded within it, which is not visible to the user. Data is translated from the graphical interface to the terminal emulator, a process called "screen scraping". This has some advantages, in particular, it avoids the need to recode the mainframe application. However, the approach feels messy and was generally seen as a transitional arrangement, not a strategic solution.
To improve on screen scraping, the next generation of fat clients communicated with SQL databases. This is cleaner and more efficient than screen scraping, and allows applications to further benefit from the power of the PC. Unfortunately, this design completely changes the security considerations, and makes it much easier to introduce unintentional vulnerabilities.
The way that a database client communicates with the server is completely different to the user interface. When a user clicks "View orders" the client sends a command like SELECT * FROM orders WHERE user_id = 1234. The user interface should still apply the correct security controls, and if they don't, that would usually be detected in functionality testing. However, an attacker has far more opportunity to tamper with the communication. They could connect with a command line SQL client and send SELECT * FROM orders WHERE user_id = 1235 - and access orders for another user. While it is possible to have the database server correctly control access to data, it is not obvious this needs to be done. Compare this to the mainframe terminal application, where it was much clearer where controls needed to be applied.
There are other issues with database fat clients. Authentication is particularly challenging, and attempts to build application-layer authentication tend to be flawed. And an unprivileged database user typically has access to all sorts of advanced database functionality, which can be prone to privilege escalation flaws.
In fact, the security of database fat clients is almost universally poor. The one saving grace is that such applications tend to be used internally within organisations.
As people started doing business online, web applications started processing sensitive personal data. There is more risk here because web applications are exposed to the whole Internet. It was understood from the start that security was important, and this led to developments like SSL to protect data with encryption. However, HTTP forms have a similar design problem to fat clients: the client-server communication protocol is very different from the user interface. The web page may appear to disallow normal users access to administrative functions, but hackers have many opportunities to tamper with communication and gain unauthorised access. This has led to all sorts of security problems, including most of the OWASP Top 10.
Web applications have a different architecture to fat clients. Fat clients communicate directly with the database. Web clients communicate with an application server, which communicates with a back-end database. This is generally a good thing as it's easier to implement security in an application. However, it also introduces new risks, such as SQL injection.
Another new area of risk is cross-site vulnerabilities. Fat clients usually connect to a single back-end, and each fat client is separated from others. However, web browsers can communicate with multiple web sites, and a certain amount of inter-site interaction is possible. The "same origin policy" attempts to solve this, but has led to whole classes of vulnerabilities like cross-site scripting which remain a serious concern.
Another issue is that users may download malicious software from the Internet, so their PC is no longer trustworthy. This was never a concern with a dumb terminal - without any local processing capability, it simply wasn't possible for malicious software to take it over. While multi-factor authentication can help defend against malware, it remains one of the greatest security concerns.
As well as human-to-computer interactions, people want computer-to-computer interactions. For example, when an employee enters a customer's order, if something is out of stock, an order is automatically placed with the supplier. There have been all sorts of standards to support this need.
There is a major security advantage to web services: the user interface closely corresponds to the actual communication. The web service is designed to be used by a programmed client, so the service implementors know to expect all kinds of input. It is certainly possible to have vulnerabilities - but the design discourages them.
Also, modern web services standards attempt to build more security features into the core technology, so there is less responsibility for developers of individual services.
Many organisations are aware of the security risks of fat clients, but is difficult to fix them. The application may have been built with long-obsolete tools, by people who moved on years ago. And the business impact of breaking such an application could be massive.
One defensive approach is to use application remoting. Instead of running on the user's PC, the fat client actually runs on a central server. An application remoting protocol displays it on the user's screen, and sends all the keyboard and mouse events back to the server. This is quite a clever tactical solution, as it removes the ability of an attacker to send custom SQL queries that break the security model.
However, Windows was never really designed to be secure in this manner. It's often possible to break out of the fat client and access a command prompt on the application server. At that point an attacker can send custom SQL queries and break the database security. There are some advanced systems to try to stop this, but ultimately you are trying to retrofit security onto a system not designed for it.
An alternative approach to fat client design is to have the client communicate with a web service, which communicates with a back-end database. This is a very appealing design, and was the basis of Microsoft's .Net strategy. The web service should be designed so that any client can access it securely, potentially even being exposed to external partners. The design also avoids screen scraping and lets the application leverage all the advanced functionality available.
Web service clients seem to be a great architecture, and single-page applications bring that to the web. Early web applications made minimal use of JavaScript, but SPAs turn that around completely and are entirely reliant on JavaScript. Architecturally, they are web service clients that are written in JavaScript.
SPAs are a relatively new technology, so there may be issues that come to light, especially around cross-site attacks. But early indications are positive.
A development of the web services architecture is "micro services". Rather than one almighty application server that runs everything, have a number of micro services. The security considerations are still being figured out.
Application tiers change the role of the database. Previously there was great need for smart databases with lots of features. Now it may make more sense to put most of the smart features in the application tier and leave the database to focus on what it does well: storing and retrieving data. The growing popularity of NoSQL databases reflects this.
Information security will be an issue for the foreseeable future. I believe it is a technology problem with technology solutions. Development frameworks need to provide security features that make it easy to build secure applications. Applications should have their security built-in, turned on by default - so users don't have to think about it. Users will always have some responisibility for security, but IT professionals need to make it simple enough for my Grandma to understand.
I've made some bold claims and probably a few factual errors. If you want to discuss these, please go on Reddit NetSec.
I enjoy writing content, but could use some help with presentation. If you wan to help out, drop me an email.