Friday, July 31, 2009



This myth has a little bit of background in the Globalization testing Myth# 12 . This post is rather an extension to the before-mentioned post.
While performing the Globalization testing, one of the key test environment specific decisions is whether to use native language Operating system or make use of MUI packs as Microsoft provides both the options for its users. The previous post does touch upon this aspect. As i delved more into this topic, i had a realization that MUI packs do not actually behave the same as the different flavors of Windows Operating systems. With a bit of research, i was able to arrive at the below table listing the differences between the way MUI technology works in Windows XP and Windows Vista. This information has largely been derived from the below mentioned sources.



CategoryWin XP Win Vista


MUI architectureSome part of Win XP code is language dependent (e.g. country specific device drivers)Separates the language resources for the user interface completely from the binary code of the operating system.
All installations of Windows Vista contain at least one language pack and the language neutral binaries that make up the operating system.


Mode of InstallationMUI Packs can be installed over English version of OS only.Language Packs can be installed on any language version of Windows Vista. E.g. a user having Spanish Vista Ultimate can install German Language packs and switch between these 2 languages on the same system.


Maintenance updatesWindows XP usually releases one Service pack per languageBeing completely built o language neutral code base, Windows Vista can be updated by a single software update anywhere in the world


UpgradesThe Multilingual User Interface Pack only supports upgrades from English versions in case of Windows XP.All upgrades must be performed in the same language in case of Windows Vista.
Vista Home Basic (EN)-> Vista Ultimate (JA) not allowed.


Licensing requirementsFor non Win Vista Ultimate, Vista Enterprise installations: Only single language installation.
For these editions, Windows will automatically remove all non-default languages from the computer after the end user completes the Windows Welcome.


File and folder names created at setupIn case of Windows XP, the files and folder names created at setup such as "Program Files", "Documents and Settings" etc. remain in English language.In case of Windows Vista, the corresponding Files and Folder names created during setup changes to the language of the MUI pack.


Multiple Languages on same InstallationWindows XP allows having multiple languages on the same computer system provided the original language of OS is English.Available with any language


Languages support4297



Saturday, July 11, 2009

Uncovering Myths about Globalization testing- English version on Localized setup


This myth has a little bit of background in the Globalization testing Myth# 3 i.e. Globalization testing actually should start much before the International product is translated i.e. the User Interface, Documents etc. start showing up localized. The question here is how is the Internationalization testing done when the translated product is not available. I will just attempt to explain this in various points below-

Does English version of product and International version of product gets released for testing at the same time ?
In a more matured Software development life cycles, the code complete specific to English version of the product and the International version of product gets submitted at the same time i.e. one single English build have the code changes specific to International version as well.
In some Software development life cycles, the Internationalization specific changes gets introduced only after English build is released.

Can translation of product happen before English product's User Interface is frozen ?
Also, it is a well known fact that the in an ideal scenario, the Translation of product User interface into supported Localized languages happens only after English product's User Interface is Frozen.
* English product's User Interface is Frozen only after some cycles of testing in which entire User Interface is tested in different setups (OS, browsers etc.) to ensure that there all the User Interface specific issues are found and fixed before the different texts are translated. And even after User Interface freeze, the translation activity acually takes quite a bit of time because it is usually a manual process and has its own cycles of reviews before translation gets finalized.
* It is quite evident that since the time first build with Internationalization specific code changes is introduced to User Interface Freeze milestone to actual Translation of the product, there is a lot of time that gets elapsed. If Internationalization testing does not start when the first build (usually English build) is received, then many of the Internationalization specific changes will not get found until the Test team receives the translated build.

How can Internationalization testing happen when there is no translated software available ?
* The answer to this question is testing English version of the product on Localized setup e.g. Say a product is supporting German and Japanese languages and supports Windows XP, Windows Vista, Mac 10.5 OS- Internationalization testing in this case would involve testing English product on German Windows XP with German Internet Explorer 7.0, testing English product on Japanese Windows Vista with Japanese Firefox etc.

What kind of bugs is this type of testing (Testing English product on Localized Operating systems) helping to find ?
One may always argue that testing English product on a Localized version of the Operating system will always result in English specific issues because what we are essentially testing is the English product. This may be true to some extent but not entirely. Consider the below situations-
* The Product installation works fine when English product is installed on English Operating system. The Product installation fails when English product is installed on Spanish language. The reason- the Install Path name is hard coded in the product. The product usually gets installed in "Program Files" folder in Windows. "Program Files" folder is called as "Archivos de programa" in Spanish language.
* The data input using English characters e.g. Writing the name as "Anuj" works fine in English Operation system. When using the same build on Japanese Operating system and using the name as "廃れる" fails. The reason- the product does not recognize the Japanese language data.
These are just a few basic examples and there can be many such instances of unique bugs that can be found (i will cover this aspect in more details in upcoming blogs)

Keep testing passionately and do provide your feedback to me!

Friday, July 3, 2009


This post is a continuation of my previous post based on the real time myths about Globalization testing as i have experienced.


One of the intriguing areas in the sphere of Software Globalization testing is planning/performing testing of the international application from the security perspective. One of the popular myths or rather assumptions when talking about Globalization testing is that the software applications usually do not have any impact as far as Software Security is concerned and thus the Security testing is not required to be done on an International application. While this may be true in certain contexts but there is also a large possibility that system security gets compromised with incorrect assumptions about the topic. Security related bugs usually have a high business impact and are (in most cases) costlier to fix than the related functional bugs.
Without doubt this is a much broader topic to be reasonably covered in one article alone, this article is primarily an attempt to put together a "perspective" of how different security related aspects may have impact on International Software applications.

A background in possible Security considerations for International applications:
Unicode provides a unique number for every character, no matter what the platform, no matter what the program, no matter what the language. In many ways the emergence of Unicode standard has changed the way Software Internationalization has been perceived and carried out in product design. It has been one of the significant advancement over the past encoding systems. Unicode 5.1.0 contains over 100,000 characters and encompasses of large number of different writing systems of the world, the faulty usage of the same may result in potential security attacks. Unicode consortium defines the major security threats related to International applications in 2 major categories-
1) Visual security issues
2) Non Visual security issues

Visual security threats:
The threats under this category are nothing but the Visual spoofs. Since Unicode consists of myriad of characters, there is a good probability of a layman user coming across visually confusing strings. There are no hard-and-fast rules for visual confusability- many characters look like others when used with sufficiently small sizes, in different font, considering different sequences of characters e.g. In some cases sequences of characters can be used to spoof: for example, "rn" ("r" followed by "n") is visually confusable with "m" in many sans-serif fonts.
As security expert Eric Johanson mentions in an advisory, a security weakness in a standard for handling special character sets in domain names could let an attacker spoof Web sites. There are now many ways to display any domain name on a browser, as there are a huge number of character sets which look very similar to Latin characters. The advisory demonstrates the attack using the domain for PayPal, but using an alternate Unicode character for the first "a." That gives an address that looks like "http://www.pà," but with a "à". This can enable an attacker to create a fake Web site for a phishing scam.

Non Visual security threats:
Non Visual security threats primarily deal with how the Unicode data is interpreted by the system. There are different security flaws that can be exposed by indifferent use of Unicode data by the system. Some of such attacks include-
UTF-8 Exploits, Text Comparison, Buffer Overflows, SQL Injection Vulnerabilities, Cross-Site scripting, Format String vulnerabilities etc.

Potential Security tests on International applications:
For the sake of simplifying the usage of the tests, the Security tests on the International applications can be divided as-

1) Security tests based on Functional requirements
2) Security tests based on Non-Functional requirements

Security tests based on Functional requirements:
These tests validates the Security sensitive functional portion of the system. The tests that would primarily come under these categories would pertain to applications'-
a) Authentication
b) Authorization

Authentication and Authorization tests usually go hand in hand.

If the application is going to be used in International markets, then the relevant Security tests here would be-
- To use the International characters in the supported languages. From the Security perspective, depending upon the reach of the product - the test characters can be of languages not supported by product but are supported by Unicode.
- If the product authorization is dependent upon presence or absence of an dependenant application, for an international application it will make sense to use Localized version of the applications.

Security tests based on Non-Functional requirements
Non-functional security requirement can be something like “System should not be compromised.” As is clear from the wordings, this requirement is not associated with a specific feature and it’s a very generic but an important requirement. In order to look at the Security aspects of an application accurately, it is necessary to have a holistic view of the situation. The most predominant challenge is that if the requirement is as vague as the one mentioned above, there is no one simple test be performed to make sure that the security requirement is met.
One of the possible approach that can be used to find such vulnerabilities is to generate the Flaw specific test ideas. The obvious question is which flaws to consider. Below listing has a mention of few flaws that can potentially have an impact on Internationalized applications and some ideas on how the tests can unveil these. This, by no means is the complete list of Security tests for International applications.

a) Buffer Overflow vulnerability:
o About the Buffer overflow vulnerability-
Buffer overflows occur in the software written in programming languages that do no strictly enforce bounds checking on arrays. The basic concept of a buffer overflow is that we provide an application with more data to be stored in a particular variable than the programmer setup the space for. When this happens, it is likely that the application writes past the bounds of the variable buffer, allowing an attacker to change the value of other data stored in memory and even execute the malicious commands. It is easiest for the attacker to perform buffer overflow attacks on the stack. These attacks can happen over heap but considering the dynamic nature of heap, these are usually difficult to simulate.

o How can this vulnerability impact Localized applications-
One of the possible ways this vulnerability can impact Localized applications is that the application may have typical checks built-in regarding ASCII text but the entering the Unicode data may expose the buffer overflow vulnerability.

o Possible tests on Localized applications to unveil Buffer overflow vulnerability-
1. Identify the areas of the application that are potentially vulnerable. Majorly, it would all the areas where the application accepts user inputs and particularly the areas that are exposed to wider audience. Potential candidates for this type of vulnerability would be any text fields within application that do not have any input validation check.

2. The Localized application might have done the Input validation on the text fields by virtue of number of characters supported e.g. Say, an Input field is programmed to accept maximum of 45 characters for the name field. If the character input is in English, the 45 characters will amount to 45 bytes in case of UTF-8 encoding. But if the character input is in Japanese, then depending upon the character input one character might take 3 bytes- which will amount to 45*3= 135 bytes of "acceptable" data input. Such an application is potential candidate for buffer overflow vulnerability attacks, as this gives an opportunity for the attacker to input malicious code along with the input text.

3. Depending upon the underlying encoding system in use, number of bytes a character occupies varies e.g. the character "は" occupies 2 bytes in UTF-16, 3 bytes in UTF-8 and 5 bytes in UTF-7. Thus, by using character driven Fuzz techniques the test data can be generated to simulate a situation when the character data exceeds the available buffer space.

4. Converting strings between different character encodings (such as SBCS, MBCS, Unicode, UTF-8, and UTF-16) may produce a buffer size mismatch. Being aware of the areas where such conversion is happening in application may aid the test team to focus to find this vulnerability.

5. If the application reads certain text or data embedded in the communications protocol, this source can be populated with localized text to simulate the buffer overflow attacks. e.g. by some internal operation of the program, the string may expand- which will result in enlargement of the buffer. Strings may expand in casing: Fluß → FLUSS

b) SQL Injection vulnerability:
o About the SQL Injection vulnerability-
SQL injection is an attack in which malicious code is inserted into strings that are later passed to an instance of database server for parsing and execution. The primary form of SQL injection consists of direct insertion of code into user-input variables that are concatenated with SQL commands and executed.

o How can this vulnerability impact Localized applications-
This vulnerability can be tested in the applications with an interface to the database. In case the localized applications are using the database with localized schema, then this vulnerability (if existing) might be exposed by entering alternate encodings for the potentially problematic characters such as Apostrophe, Quotation mark, Comma, Bracket etc.

o Possible tests on Localized applications to unveil SQL Injection vulnerability-
1. Make a note of all the user input fields that commit the data to the database.
2. Generate the test data that includes the data changing or even schema changing commands. There are a lot of publically available SQL vulnerability cheat sheets available that can help generate the relevant test data depending upon the database being used.
3. One of the key changes that could be made to the test data is to use the equivalent characters in the different supported languages.

c) Other Security vulnerabilities:
One of the more methodical ways while considering the Security testing for International applications is to commence with the creation of appropriate threat model. A threat model is a description of a set of security aspects; that is, when looking at a piece of software (or any computer system), one can define a threat model by defining a set of possible attacks to consider.
There are other notable Security vulnerabilities that can have potential impact on the security of International applications (and can be considered in threat modeling) such as Format String vulnerability, canonicalization exploit and with more Software vulnerabilities being found with each passing day, the list of vulnerabilities having impact on International applications can never be fixed but would always be ever growing.
Local governments may have their own specific security requirements. For example, any product that either uses or implements cryptography for confidentiality must obtain necessary approvals from the French government prior to shipping to France.

It is quite evident that the International application does bring out the unique challenges from Security perspective. There is a certain intersection between Security testing and Globalization testing, something that cannot be ignored. The adage "Security testing is from Mars and Globalization testing is from Venus" is possibly not quite right! and this is certainly one area that is waiting to be explored further and researched.