Web Content Lockbox - Page 2

Not Foolproof

Although Applock/Web keeps vandals from changing Web pages and content, it doesnt stop them from adding new pages. This makes it possible for attackers to add their own Web page and then direct users to it from a chat room or newsgroup. Anyone visiting this page would probably think it was legitimate, because it was being served from the companys Web server. If the added page has the same look and feel of the real Web pages on the site, this type of hack can be very successful.

Also, for a sites contributors to legitimately change the content, they need to first turn off AppLock/ Webs protection capabilities. This could be a needless bother for companies that change content regularly. It could also be a problem for sites that use a dynamic content management system but then serve the pages as static HTML.

Forcing an administrator to manually shut down AppLock/Web on a Web server before any change can be made effectively negates the benefits of a content management system. This means AppLock/Web is probably best suited for Web sites whose content remains fairly static.

However, when it comes to protecting content within the scope of its design, AppLock/Web does a very good job. In tests, the program looked for content on our Web server and locked it against unauthorized changes.

Once we entered our password (and the program enforces very strict password protocols), we could view all files on our servers and choose which ones to protect from changes.

It was impossible for us to change any content on the server, and we couldnt even access Microsoft Management Console for IIS while AppLock/Web was in lockdown mode. In addition, we tried several methods to disable AppLock/Web by shutting down services and processes but were unable to stop its protection of the server content.