From the site, http://www.softwareqatest.com/qatfaq2.html, I came across this statement. There are many forms of software testing. What I am discussing herein is related to white-box testing, automation and framework development, performance, and security testing

What makes a good Software Test engineer?

“A good test engineer has a 'test to break' attitude, an ability to take the point of view of the customer, a strong desire for quality, and an attention to detail. Tact and diplomacy are useful in maintaining a cooperative relationship with developers, and an ability to communicate with both technical (developers) and non-technical (customers, management) people is useful. Previous software development experience can be helpful as it provides a deeper understanding of the software development process, gives the tester an appreciation for the developers' point of view, and reduce the learning curve in automated test tool programming. Judgment skills are needed to assess high-risk or critical areas of an application on which to focus testing efforts when time is limited.”

In my opinion, more emphasis should be placed on the statement italicized above. Taking it a step further, I would say a developer with previous development knowledge of the product under test is even more valuable. Obviously domain knowledge is what increases this value. From previous experiences with organizations, the development skills of the tester are often largely ignored.

“Writing code? That’s what our developers do, not our testers.”

If we are not placing a greater emphasis on the development skills of the tester, we are missing opportunities to fully test the product. Testers with a development background are more familiar with the developer's perspective. They know the tricks developers do when writing code, they know their shortcuts and tendencies. These testers can also provide developers with insight into defensive coding, adding hooks to make automation easier, securing the product from attacks, ect.

I would argue the inverse is true as well, that having previous testing experience of the product would add value to the transition of a tester into development. A developer with a testing background should improve the testability and security of the product, because they, too, understand the importance and impact of test.

To me, test and development should be shared responsibilities. If a developer is out sick, on vacation, or the team needs a resource, a tester should be able to fill in, developing product code. If a tester is needed for similar reasons, a developer should be able to switch gears and fulfill that need as well. Neither should be more exciting nor glamorous. The organization should respect both disciplines equally. Testing is the last line of defense.  

The software engineer should have two personae, constructive and destructive. Perhaps this is similar to Dr. Jekyll and Mr. Hyde, where we replace the “evil” in Mr. Hyde with “destructive product testing.”

Think your web applications are safe from cross site scripting? Maybe, maybe not. Why take a chance?

I recently put together some notes for a presentation on cross site scripting, or XSS for short. I have decided to share some of the information, because I believe keeping a few thoughts in mind as we develop and test will go a long way when it comes to preventing attacks.

Cross Site Scripting – What is it?

Cross site scripting occurs when a web application gathers malicious data entered from a user, with or without negative intent. XSS can be achieved by exploiting locations in source code where users are able to input data, and the proper preventative measures have not been implemented to format and validate the inputted data. In other situations, session cookies and other sensitive data can be accessed by injecting malicious data and ultimately hijacking or impersonating a user’s account.

There are three main types of XSS according to Wikipedia, so I won’t bother rephrasing. Visit http://en.wikipedia.org/wiki/Cross-site_scripting for more information.

The most common technologies and languages used for XSS are JavaScript, VBScript, ActiveX, HTML, or Flash’s ActionScript. Not only do we need to protect our server code, but we need to think about our client code as well.

Prevention of Cross Site Scripting

The vast of majority of XSS attacks can be prevented by identifying the user input locations within the web application and ensuring the source code handling these has proper measures in place. From a developer’s perspective, this means ensuring all data inputted from a user is properly encoded to remove HTML and script markup to be replaced with text that all browsers can process.

A simple example in C# is to use the HttpServerUtility.HtmlEncode method to convert all HTML markup characters into their text equivalent. For example, if a user were to supply the input for a textbox with the following, “This is my <b>bolded text</b>.” The end result of the HtmlEncode method would result in the following, “This is my lt;bolded textgt;.” This is important because it removes HTML markup, which could be malicious. For example, “This is my text. <script>alert(‘This is an attack’);</script>.” This example is passing a JavaScript alert to open a modal popup on the screen to display to the user.

In addition to HTML inputted data encoded on the server, encoding data on the client can be equally important. JavaScript HTML elements can have two attributes, InnerHTML and InnerText. InnerText will render text, not HTML, so it is the safe option. InnerHTML can be used to inject an XSS attack because it can render user inputted HTML, including script. Ensure InnerHTML has the necessary string formatting to protect against this vulnerability.

Cookies are another vulnerability to XSS attacks. If any part of the website issues cookies and an XSS access point is discovered, it is now possible to steal cookies and private information from the application’s users. If the cookie can be accessed, so can the information with it. Users can be impersonated, and site credibility will be lost.

Encrypted web sites (SSL, HTTPS) are at risk just like their public counterparts. SSL sites appear to be protected, but it is possible to execute the same XSS attacks, they just happen over an encrypted connection.

To protect our web applications, we need to be aware of the XSS vulnerabilities common to attackers and place defensive measures to ensure user confidentiality and confidence. Without becoming an expert on XSS and security, it is possible to develop safe, reliable applications by understanding XSS and the vulnerabilities exposed by our applications.

What to Look for in Source Code

Execute a simple search in source code looking for certain keywords is a good starting point. Many of the XSS bugs I have seen reported could have been prevented with the simple measures. Ensure HTML input is properly encoded on the server using HtmlEncode. Ensure HTML input is properly formatted on the client using string.Format and InnerText.

In source code and wherever, look for the following vulnerabilities.

• InnerHTML
• InnerText is not supported by all browsers but the two can be found together. Look for where the strings are originating and if they are properly formatted/encoded.
• SetInnerText()
• JavaScript’s Eval()
• Don’t be Eval - http://24ways.org/2005/dont-be-eval
• Assigning of strings to page titles, control titles, ect.
• Sometimes we take request object data and immediately process it and render it on the client.
• Check the URL parameters passed in.
• The Request object
• Request.Params
• Request.Forms
• Request.QueryString
• Using HtmlTextWriter or any variation
• RenderBeginTag()
• AddAttribute()
• RenderEndTag()
• HtmlWriter.Write()
• Cookies
• Where are we using them and how are we handling them

Searching for these keywords within source will be a decent starting point for discovering XSS vulnerabilities

Microsoft Anti-Cross Site Scripting Library V3.0 Beta

Feel free to use a Microsoft API designed for XSS prevention within your code.

http://www.microsoft.com/downloads/details.aspx?FamilyId=051ee83c-5ccf-48ed-8463-02f56a6bfc09&displaylang=en

Closing Notes – because this topic can go on forever

There are tools to help assess if your site is vulnerable. Search for them online. Whether or not you think you need third party APIs to help you write defensive code is entirely up to you. You can always write the code yourself.

Cross-site scripting (XSS) can be damaging to a company’s credibility and can cause myriad undesirable effects for individual users. XSS is preventable. Familiarizing oneself with the smells of XSS is a valuable tool to posses as a developer and a tester. At a minimum, educate your developers and testers on the target hot-spots mentioned within this post.

References and Resources

http://en.wikipedia.org/wiki/Cross-site_scripting

http://www.cgisecurity.com/xss-faq.html

http://ha.ckers.org/xss.html

http://www.owasp.org/index.php/Cross_site_scripting

For the past six months I have transitioned into a new role at a new company. I am now a software tester. For the past eight years, I have spent all of it but six months developing software, writing code, and thinking testers were individuals who chose a comfortable, stress-free career path, where they might be found playing World of Warcraft or reading science fiction novels in between periods of pretending to do work.

There, I said it. Now the healing can begin.

What was I doing for those six months when I was not developing? I began my career as a tester fresh out of school. I worked closely with a developer, we all worked in pairs back then. I discovered the work he was doing in development was sexier than what I was doing in testing. The rest is history.

"Software testing is  process, or a series of processes, designed to make sure computer code does what it was designed to do and that it does not do anything unintended. Software should be predictable and consistent, offering no surprises."

Yawn.

If you are still awake, I appreciate that. If you share my sentiment about testing, I cannot fault you. For the same reasons I wanted to get out of testing and into development, I was hesitant to get back into it.

Sadly, I had preconceived notions of what testers do and what skills and career goals they possess based on previous organizations.  For example, it was easy for me to generalize that the testers with whom I encountered were not as technical as developers, they were not writing code nor had any desire, and they wanted to get into the technology field but did not want to earn a CS degree. It was an easy way in. These are all erroneous generalizations that I regret thinking at one point in time, and for the most part, they were geared towards black box testing.

With testing comes new challenges. What I have read, and what I am trying to apply to my work, is the idea that the "attitude of the software tester may be more important than the software process itself."

In a nutshell, what this implies is that testers should approach their craft by trying to uncover the errors and failures within the product, rather than trying to prove the product works as expected. A tester should be disappointed when he/she cannot find errors, failures, bugs, ect. The mentality has shifted from constructive to destruction by nature.

As developers, we focus on developing a product, creating or constructing something. The subconscious wants to see it succeed, if not willing it to succeed. The attitude is constructive. If we approach testing the product by proving it contains no errors, we may subconsciously be influenced to choose data proving no errors exist, ultimately reducing our chances of discovering failures and defects.

As testers, our attitudes need to become destructive. This transition is difficult for some, since most of us approach our work constructively, meaning, we are used to building or creating things, rather than destroying them. We need to destroy the product. Do what we can to break it, cause it to fail, and bring it to its knees exposing weaknesses, vulnerabilities, and the many errors and bugs that do exist.

As testers, we write tests, test cases, and we strive to automate as much of it as possible. We even strive to automate the creation of more test cases. If our tests fail, they are successful, because this means our tests prove errors exist. When errors exist, testers are happy - developers are not.

Much has changed with my perception of software testing, starting with a fresh, new outlook and an attitude adjustment. And oh yeah, I forgot to mention, all those core object-oriented principles, practices, patterns, and frameworks, those are equally important in the world of testing as they are in development.

I work for an organization where heavy emphasis is placed on testing. I now spend much of my time developing automation frameworks and controls used to author tests. In addition, I am tasked with building a system to implement and measure code coverage, and investigate fuzz testing and model-based testing. This is hopefully the first post of many pertaining to and influenced by testing. Read more about the SDET versus the SDE here.

References: