Anatomy of a Hack

SBC's Web hosting

I asked Caleb to give me an idea to find these vulnerabilities so quickly, and he came up with a few suggestions. If you understand how Web servers work and how they have directory structures and input forms just like your computer on your desktop, you can get pretty far -- even without much other specialized knowledge. To give you a flavor of this, I submit his prescription for locating a Web application attack vulnerability called cross-site scripting.

Cross-site scripting occurs when dynamically generated Web pages display input that is not properly validated. This allows an attacker to embed malicious JavaScript code into the generated page and execute the script on the machine of any user that views that site. Cross-site scripting has some far-reaching implications, and can impact any site that allows users to enter data. You see this on search engines, in error message screens, in forms and Web message boards, among other places. (You can read more about this at SPI Dynamics' site.

Here are the steps to see if your Web applications are vulnerable to this attack:

Step 1: Open any Web site in a browser, and look for places on the site that accept user input, such as a search form or some kind of login page. Enter the word test in the search box and send this to the Web server.

id
unit-1659132512259
type
Sponsored post

Step 2: Look for the Web server to respond back with a page similar to something like "Your search for 'test' did not find any items" or "invalid login test." If the word "test" appears in the results page, you are in luck.

Step 3: To test for cross-site scripting, input the string "<script>alert('hello')"</script">" without the quotes in the same search or login box you used before and send this to your Web server.

Step 4: If the server responds back with a pop-up box that says "hello", then the Web site or Web application is vulnerable to cross-site scripting.

Step 5: If Step 4 fails and the Web site does not return this information, you still might be at risk. Click the "View Source" option in your browser so you can see the actual HTML code of the Web page. Now find the <script> string that you sent the server. If you see the entire "<script>alert('hello')"</script>" text in this source code, then the Web server is vulnerable to cross-site scripting.

If these steps don't make much sense to you, not to worry. You can still get some mileage, particularly when you are in the throes of picking a hosting provider. I suggest that you might want to send them this column and see what kind of response you get from them before you give them your business. If you get no response or a canned response, then you probably should go elsewhere. You could also send this column to your IT department. If they don't understand what I am talking about here, then you might want to bring that to the attention of your CEO and find out why.

There are plenty of other Web site vulnerabilities, as I mentioned in my last column. Hopefully this will get you motivated to seek them out, either by using SPI Dyanmics' product called WebInspect or someone else's, and by being more diligent about what applications you allow access to your Web content.