Databases Reference
In-Depth Information
Finally, ensure that passwords are not simple strings. Recall that rainbow tables contain hash values
of common strings or likely passwords. There are over 800,000,000,000,000,000 passwords with ten
characters. Hash tables can't contain all of these passwords. By choosing a strong password, your users
protect other systems that may use the same password. It is impossible to enforce that users select
different passwords for different systems, but enforcing strong password policies can minimize the
chance the actual password is decrypted. APEX now provides the ability to require strong passwords for
the APEX builder users for both the APEX internal admin screens and for individual workspaces.
Consider creating similar strong password rules for any application user management.
Key users of the HBGary website, including the CEO, did not select strong passwords and the
encryption algorithm was well known with a standard seed. The rainbow table yielded the actual
password string. Anonymous was able to log in to the website as a privileged user and change content.
With the actual password, Anonymous was also able to log into an HBGary Linux server. The operating
system on this server had not been patched for a known security bug, allowing the hackers to elevate
privileges of the logged-in account. The elevated privileges provided access to proprietary HBGary
content.
The easiest way to get a password may be to simply ask for it. After Anonymous used a rainbow table
to decrypt the CEO's password, they logged into his email account with the same password. A review of
past emails provided an idea of the CEO's email style and a good idea of who might have passwords to
other servers. A quick email from the CEO's email account to a system administrator asking for a root
password is all it took to get into yet another server.
Cross Site Scripting
Though not involved in the WikiLeaks story, cross site scripting should be mentioned in any article
about web security. Cross site scripting involves inserting unexpected Javascript into a page. A browser
requests a web page from a server and the server returns HTML, possibly with Javascript embedded.
Most web applications require Javascript. A browser has no way of knowing if the Javascript returned
with the page is intentionally there or whether it has been injected. It is the developer's responsibility to
make sure that malicious Javascript does not show up in the HTML returned.
Consider a report that does not escape data that is selected from a table. If the data in the table is a
string containing a Javascript tag, the report will send the data directly to the browser and the script will
run. For example, given a select statement:
select address1, address2, city, state, zip, comments
from order address
the comments field is likely fairly long and could contain the string:
<script>alert('hello');</script>
Given a classic report, with the COMMENTS report column “Display As” set to Standard Report
Column, the data will not be escaped. The browser will interpret the <script> tag to mean that it should
run the included script. The result will look like Figure 8-19.
