Security Bulletins and Fixes
8/29/07 - Search Engine Listings.
Problem: It has come to our attention that some pages protected by WebBuild Password Security are showing up in Google and other search engine listings.
Discussion: After investigation, it appears that the pages were indexed by the search engines before they were protected by WBPS. After WBPS protection has been added to the secure pages, the listing in Google may remain, but if a user clicks on the Google link, he or she will (correctly) be redirected to the Password Error page because he or she has not logged into the site. The contents of secure pages that were earlier cached by the Google robot may remain in the Google listings, however.
Solution: The easiest way to prevent search engines from indexing WBPS secure pages is to ensure that you do not deploy them to the server until the WBPS 'Secure Page Code' has been added to their HEAD sections.
If, however, a secure page shows up in Google or other search engines, you should immediately consider the following actions:
3/26/07 - Secure page vulnerability.
Problem:A customer recently reported that a secure page that he had protected with the JavaScript code produced by the WebBuild Password Security program could be viewed with Microsoft Internet Explorer with an unusual combination of security settings.
Discussion: This issue is inherrent in the architecture that WBPS uses to develop secure sites. WBPS is designed so that it will run without any server-side scripting or programming. As a result, all the pages in a site protected by WBPS are physically present on the server and will be served to anyone who knows the pages' addresses and requests them. The Secure Page code that WBPS produces has code that will redirect an unauthorized usr to an error page, and it will protect a secure page from most viewers. A determined and sophisticated outsider, however, who wants to access the page will be able to do so -- no matter how well protected -- if he/she knows its name and location on a site. This can be done by manipulating a browser's security settings (as was reported by our customer) or by viewing the page by other means than a browser.
A security scheme that is dependent on server-side programming can avoid this pitfall by ensuring that a user is authenticated before creating the page and serving it to the user. Since the page only exists after the server has chosen to create it, this affords a protection that a non-server solution cannot offer.
Solution: The best way to ensure that this vulnerability does not allow outsiders to view sensitive content on a site is to use unguessable page names. One way to do this is to generate two sets of random eight-digit alphanumeric characters separated by a dot (for example: 7z18pg0e.hvo1lphf.htm or cfz14a06.ago46i8g.html). It will be very difficult for an outsider to guess that a page name exists that was created by this technique. (If someone tried to guess the name of such a page by a "brute force" technique, and had the ability to attempt 1,000 "guesses" per second, it would take him or her 2.5 million trilllion years to find a page with a random 16 character name).
Pages created with WebBuild Password Security obfuscate the names of secure pages so that they do not appear in a manner that an outsider can discover them. A sophisticated outsider who examines the code that WBPS uses to perform validation of usernames and passwords will see code that contains references to page names, but this data is strongly encrypted. Without the keys provided by the usernames and passwords, it is virtually impossible for an outsider to learn that a page named something like 7z18pg0e.hvo1lphf.htm exists, so he/she will not be able to access the page.
If you need help assigning page names or assessing the strength of a page-naming convention that you use, please contact our Technical Support staff at TechSupport@WBPS.us.
Whatever you do, do not give your secure pages obvious names like "Members.htm" or "EmployeePage.html". In addition, make sure you do not refer to the name of any secure page, either on your Web site, or in any other publically accessible place. Finally, change the name of your secure pages on a regular schedule, update the references to the new name in WBPS, recreate your WBPS Password Sets, and move the resulting files to your Web server.
9/30/06 - Multiple Cookies.
Problem: Sites that use WebBuild Password Security sometimes experience unexpected problems when they use other software that places cookies on users' computers.
Discussion: Tracking programs (like Google Analytics), advertising, hit counters, etc. are a few of the programs of this nature. These programs often require the use of a cookie on a visitor's computer. In some cases, WBPS will display an error message to a user, even though he or she has been correctly authenticated after entering a valid username and password.
Solution: WebBuild Password Security Version 1.1.4 (and all later versions) incorporate logic that more accurately distinguishes the WBPS cookies from those of other applications. Uses should click here and follow the instructions to install the latest version of WBPS. |
|
