Web-based applications are becoming more and more common, and unfortunately coming more and more to the attention of IT Security. It seems that every day we hear of data theft from corporate websites and theft of user data from personal devices. Web applications are also becoming more intrusive in the collection of information about users and their use of the Internet.
It’s not always obvious that you are being tracked. Websites often have applications as a hidden addition to user interaction. These additions can be a simple tracking application or something far more sinister. This is particularly true of web based applications on mobile devices where malware detection and removal is not as well developed as that of desktop devices. The speed to market nowadays required of mobile applications can mean that security considerations are not dealt with properly, and hackers can compromise those applications with relative ease.
There are also concerns within the IT Security community that web-site generators used by end-users to create personal and small business websites do not build in proper security features.
IT Security is fast becoming an essential component of Webapp development.
A good point of departure is that of authentication and authorisation. A lot of trouble can be avoided by, firstly understanding the difference between the two, and secondly by implementing them properly in the app. Simply put, authentication is establishing that a user trying to gain access is known and trusted, and authorisation is managing what they can do following successful authentication. Get that right and a lot of the troubles noted below will fall away. That involves IT Security at both design and programming stages.
The first area, and one of the most exploited is that of local data storage. Web applications can hold information locally allowing users to store information to remove the need to re-enter it again later. User-id’s, passwords and banking or credit card information is particularly vulnerable. A bit of malware added to a legitimate website or local malware on the end-user device could be used to upload sensitive information to a hacker’s website without the user being aware of it. The obvious way around this is not to store information locally, or to encrypt it before storing or transmitting it. Of course, preventing hackers modifying your website is also a good thing.
A second consideration is that of data access. While executing an app, the data storage is exposed, guarded only by the security controls on the server and those built into the app itself. If the server doesn’t authenticate users, perhaps supporting anonymous access, believing that only the webapp will access the data, that is a loophole that could be exploited. Use of API’s particularly on the back-end needs to be strictly monitored.
On the question of servers, a very common problem is that of mis-configured servers. There have been cases where apps have been deployed to production with debug mode enabled, sent out with the default user ids and passwords still in place (admin/admin anyone), and other potential security holes. The dev/test/production process needs to be very strictly controlled. There are applications nowadays that can assist in managing the deployment process.
One consideration specific to apps with a client component downloaded to desktop or mobile devices is that of app distribution. There have been cases reported where apps have been modified to include malicious code and uploaded to common download sites as the true app. Developers need to include security measures to include checks that the app is genuine. Checksums, version checks during installation are some common measures.
Other things to watch out for is inter-website communications. Authentication is sometimes assumed when an access request to secure data comes from an apparently trusted source. Such requests can be forged and issued under the authentication criteria of a known site. Known exploits have included bank transfer requests. A particular type of security loophole includes unvalidated redirects and forwards, perhaps not to the site you expected. If at all possible do not use redirects and forwards in your app.
To become a little technical, security holes can be created at a programming level. The first, and sadly all too common is sloppy code. The programmer doesn’t know about the security needs of the app, or ignores them under pressure of time to complete the coding. Another variant upon this theme is copying code snippets from sources like Github. It is convenient and can save time, but has two major problems. The first is that the code, without proper checking and auditing, could introduce vulnerabilities into the app. The second, is that because it is third-party, it will not be maintained, and could introduce incompatibilities and insecurities at a later date. WordPress add-ons are a case in point.
These are a few of the more common security gaps in Web apps, but this list is by no means complete.