How to Prevent Web applications from storing sensitive data

How to Prevent Web applications from storing sensitive data

Michael Cobb is a well-known security writer who has more than 10 years of experience in the IT industry and has 16 years of experience in the financial industry. He is the founder and managing director of Cobweb Applications. The company provides IT training and data security and analysis support. Michael has also co-authored IIS Security and has written countless scientific articles for leading IT publications. In addition, Michael is also a Microsoft certified Database System Administrator and Microsoft certified expert.

In some cases, custom Web applications save sensitive (proprietary) data to your cache folder. If you do not re-architecture the application, can you use the Sysinternals SDelete logout script to ensure that the data is completely deleted and there is no recoverable residue?

Michael Cobb:Secure Delete or SDelete is a program used by the Windows Command Line. It can be used to safely Delete existing files and file data not allocated to the disk. However, you cannot use it to clear data from remote user devices. The logout script of your Web application is not granted permissions to run this powerful tool, which protects Web application data, this is a completely wrong tool. There are also more effective methods to ensure that sensitive data is not stored in the user's cache folder.

The browser saves page resources for two purposes: History and cache. The history function allows users to quickly return to previously viewed pages, while caching improves performance. The downloaded content (such as a logo or blog post) is stored in the cache folder of the User device, so that users do not need to download the content repeatedly each time they watch the content. Content stored for cache or history purposes can be viewed subsequently by viewing the browser cache or simply pressing the browser's "back" button. This may expose sensitive data such as credit card information and user names to risks.

To avoid this privacy threat, we do not need to redesign the application. You only need to use the digital certificate and some additional Cache control header fields on each web page to solve the cache information problem. First, install a Web server certificate and provide all content through HTTPS. This provides confidentiality for data transmitted between applications and users. Because the browser has different default behaviors to cache HTTPS content, pages containing sensitive information should include Cache control header fields to ensure that content is not cached. To cover various browser versions, the complete header fields that prevent content from being cached should be:

The details are as follows:

• Cache control "no-store" will prevent requests and responses from being cached and stored

• Adding "private" will place the proxy server cache page

• By setting "must-re-validate", the "Back" button no longer displays sensitive data

• The "max-age" option indicates the time when the response is cached. Setting it to "0" can prevent caching.

Nowadays, browsers usually rely less on the "Expires" header domain. To ensure security, enterprises should set the expiration time to "0" to prevent caching of older browsers. To be compatible with HTTP/1.0, the response should also include the "Pragma: no-cache" header domain. "No-transform" is very important to mobile users because some mobile operators compress or modify the content to save bandwidth.

After these changes are deployed, developers should test that applications do not expose sensitive data to the browser cache. Manual search of cache folders in each mainstream browser ensures that sensitive data is not stored. If data is found, use a proxy server such as WebScarab to check the server's response and every page containing sensitive information. In these webpages, make sure that the server is sending the correct response header domain and instructs the browser not to cache any data.