Saturday

Windows Perfmon: The Top Ten Counters
One of the things I love about Windows is Performance Monitor a/k/a PerfMon. It's an amazing tool that goes far too often unused - and when it does get used, it is often misinterpreted. So today I'm going to take you on the nickel tour through PerfMon, and the ten counters most valuable to determining overall system health and activity.

To open PerfMon, just go to the Start Menu, choose Run and type perfmon.
Bottleneck analysis

The most common use of PerfMon is to answer the burning question: why is my system running slow?

With the five performance counters listed below, you can quickly get an overall impression of how healthy a system is - and where the problems are, if they exist. The idea here is to pick counters that will be at low or zero values when the system is healthy, and at high values when something is overloaded. A 'perfectly healthy' system would show all counters flatlined at zero. (Perfection is unattainable, so you'll probably never see all of these counters flatlined at zero in real life. The CPU will almost always have a few items in queue.)

Processor utilization
System\Processor Queue Length - number of threads queued and waiting for time on the CPU. Divide this by the number of CPUs in the system. If the answer is less than 10, the system is most likely running well.
Memory utilization
Memory\Pages Input/Sec - The best indicator of whether you are memory-bound, this counter shows the rate at which pages are read from disk to resolve hard page faults. In other words, the number of times the system was forced to retreive something from disk that should have been in RAM. Occasional spikes are fine, but this should generally flatline at zero.
Disk Utilization
PhysicalDisk\Current Disk Queue Length\driveletter - this is probably the single most valuable counter to watch. It shows how many read or write requests are waiting to execute to the disk. For single disks, it should idle at 2-3 or lower, with occasional spikes being okay. For RAID arrays, divide by the number of active spindles in the array; again try for 2-3 or lower. Because a shortage of RAM will tend to beat on the disk, look closely at the Memory\Pages Input/Sec counter if disk queue lengths are high.
Network Utilization
Network Interface\Output Queue Length\nic name - is the number of packets in queue waiting to be sent. If there is a sustained average of more than two packets in queue, you should be looking to resolve a network bottleneck.
Network Interface\Packets Received Errors\nic name - packet errors that kept the TCP/IP stack from delivering packets to higher layers. This value should stay low.
To highlight a particular counter's line on the graph, select that counter in the lower pane. Then click the lightbulb icon on the toolbar above the graph. This will make the line for that counter turn thick and white (or black on some systems - I never found out why this changes).

Pay close attention to the scale column! Perfmon attempts to automatically pick a scale that will magnify or reduce the counter enough to produce a meaningful line on the graph ... but it doesn't always get it right. As an example, Perfmon often chooses to multiply Disk Queue Length by 100. So, you might think the disk queue length is sustained at 10 (bad!) when in fact it's really at 1 (good). If you're not sure, highlight the counter in the lower pane, and watch the Last and Average values just below the graph. In the screenshot below, I modified all of the counters to a scale value of 1.0, then changed the graph's vertical axis to go from 0-10.

To change graph properties (like scale and vertical axis as discussed above), rightclick the graph and choose Properties. There are a number of things to customize here ... fiddle with it until you have a graph that looks good to you.

To get a more detailed explanation of any counter, rightclick anywhere in the perfmon graph and choose Add Counters. Select the counter and object that you are curious about, and click the Explain button.

This screenshot shows a very lightly-loaded XP system, with the Memory\Pages Input/Sec counter highlighted:




All we see here is the Proccessor Queue Length hovering between 1 and 4, and two short spikes of Pages Input/Sec. All other counters are flatlined at zero, which is easy to check by highlighting each of them and watching the values bar underneath the graph. This is a happy system - no problems here!

But if we saw any of the above counters averaging more than 2-4 for long periods of time (except Processor Queue Length: don't worry unless it's above 10 for long lengths of time), we'd be able to conclude that there was a problem with that subsystem. We could then drill down using more detailed counters to see exactly what was causing that subsystem to be overloaded. More detailed analysis is beyond the scope of this article, but if there's enough interest I could do a second article on that. Leave a comment if you're interested!

General activity counters

Well, the system is healthy - and that's good ... but how hard is it working? Is the processor workin' hard, or hardly workin'? How much RAM is in use, how many bytes are being written to or read from the disk or network? The following counters are a good overview of general activity of the system.
Processor utilization
Processor\% Processor Time\_Total - just a handy idea of how 'loaded' the CPU is at any given time. Don't confuse 100% processor utilization with a slow system though - processor queue length, mentioned above, is much better at determining this.
Memory utilization
Process\Working Set\_Total (or per specific process) - this basically shows how much memory is in the working set, or currently allocated RAM.
Memory\Available MBytes - amount of free RAM available to be used by new processes.
Disk Utilization
PhysicalDisk\Bytes/sec\_Total (or per process) - shows the number of bytes per second being written to or read from the disk.
Network Utilization
Network Interface\Bytes Total/Sec\nic name - Measures the number of bytes sent or received.
In the graph below, I added these five counters to my existing 'bottlenecks' graph, and changed the vertical axis to go from 0-100. I highlighted the Working Set\_Total counter, which is currently at about 123 megabytes for the system. Notice how it shows a thick line at the top of the graph - you could assume that it was pegged at 100, if you didn't read the values bar (123,052,03 divided by a million is approximately 123 megabytes).



And ... that's all for now. Hopefully this quick show-and-tell has given you enough information to use PerfMon more usefully in

Wednesday

Parameter Tampering

Parameter Tampering

Parameter tampering is a simple attack targeting the application business logic. This attack takes advantage of the fact that many programmers rely on hidden or fixed fields (such as a hidden tag in a form or a parameter in a URL) as the only security measure for certain operations. Attackers can easily modify these parameters to bypass the security mechanisms that rely on them.

Detailed Description

The basic role of Web servers is to serve files. During a Web session, parameters are exchanged between the Web browser and the Web application in order to maintain information about the client's session, eliminating the need to maintain a complex database on the server side. Parameters are passed through the use of URL query strings, form fields and cookies.

A classic example of parameter tampering is changing parameters in form fields. When a user makes selections on an HTML page, they are usually stored as form field values and sent to the Web application as an HTTP request. These values can be pre-selected (combo box, check box, radio button, etc.), free text or hidden. All of these values can be manipulated by an attacker. In most cases this is as simple as saving the page, editing the HTML and reloading the page in the Web browser.

Hidden fields are parameters invisible to the end user, normally used to provide status information to the Web application. For example, consider a products order form that includes the following hidden field:

Modifying this hidden field value will cause the Web application to charge according to the new amount.

Combo boxes, check boxes and radio buttons are examples of pre-selected parameters used to transfer information between different pages, while allowing the user to select one of several predefined values. In a parameter tampering attack, an attacker may manipulate these values. For example, consider a form that includes the following combo box:


Source Account:

Amount:

Destination Account:


An attacker may bypass the need to choose between only two accounts by adding another account into the HTML page source code. The new combo box is displayed in the Web browser and the attacker can choose the new account.

HTML forms submit their results using one of two methods: GET or POST. If the method is GET, all form parameters and their values will appear in the query string of the next URL the user sees. An attacker may tamper with this query string. For example, consider a Web page that allows an authenticated user to select one of his/her accounts from a combo box and debit the account with a fixed unit amount. When the submit button is pressed in the Web browser, the following URL is requested:

http://www.mydomain.com/example.asp?accountnumber=12345&debitamount=1

An attacker may change the URL parameters (accountnumber and debitamount) in order to debit another account:

http://www.mydomain.com/example.asp?accountnumber=67891&creditamount=9999

There are other URL parameters that an attacker can modify, including attribute parameters and internal modules. Attribute parameters are unique parameters that characterize the behavior of the uploading page. For example, consider a content-sharing Web application that enables the content creator to modify content, while other users can only view content. The Web server checks whether the user that is accessing an entry is the author or not (usually by cookie). An ordinary user will request the following link:

http://www.mydomain.com/getpage.asp?id=77492&mode=readonly

An attacker can modify the mode parameter to readwrite in order to gain authoring permissions for the content.

SQL Injection

SQL Injection

SQL injection is a technique used to take advantage of non-validated input vulnerabilities to pass SQL commands through a Web application for execution by a backend database. Attackers take advantage of the fact that programmers often chain together SQL commands with user-provided parameters, and can therefore embed SQL commands inside these parameters. The result is that the attacker can execute arbitrary SQL queries and/or commands on the backend database server through the Web application.

Details

Databases are fundamental components of Web applications. Databases enable Web applications to store data, preferences and content elements. Using SQL, Web applications interact with databases to dynamically build customized data views for each user. A common example is a Web application that manages products. In one of the Web application's dynamic pages (such as ASP), users are able to enter a product identifier and view the product name and description. The request sent to the database to retrieve the product's name and description is implemented by the following SQL statement.

SELECT ProductName, ProductDescription  FROM Products  WHERE ProductNumber = ProductNumber 

Typically, Web applications use string queries, where the string contains both the query itself and its parameters. The string is built using server-side script languages such as ASP, JSP and CGI, and is then sent to the database server as a single SQL statement. The following example demonstrates an ASP code that generates a SQL query.

sql_query= " SELECT ProductName, ProductDescription  FROM Products  WHERE ProductNumber = " & Request.QueryString("ProductID") 

The call Request.QueryString("ProductID") extracts the value of the Web form variable ProductID so that it can be appended as the SELECT condition.

When a user enters the following URL:

http://www.mydomain.com/products/products.asp?productid=123 

The corresponding SQL query is executed:

SELECT ProductName, ProductDescription  FROM Products  WHERE ProductNumber = 123 

An attacker may abuse the fact that the ProductID parameter is passed to the database without sufficient validation. The attacker can manipulate the parameter's value to build malicious SQL statements. For example, setting the value "123 OR 1=1" to the ProductID variable results in the following URL:

http://www.mydomain.com/products/products.asp?productid=123 or 1=1 

The corresponding SQL Statement is:

SELECT ProductName, Product Description FROM Products WHERE ProductNumber = 123 OR 1=1 

This condition would always be true and all ProductName and ProductDescription pairs are returned. The attacker can manipulate the application even further by inserting malicious commands. For example, an attacker can request the following URL:

http://www.mydomain.com/products/products.asp?productid=123; DROP  TABLE Products 

In this example the semicolon is used to pass the database server multiple statements in a single execution. The second statement is "DROP TABLE Products" which causes SQL Server to delete the entire Products table.

An attacker may use SQL injection to retrieve data from other tables as well. This can be done using the SQL UNION SELECT statement. The UNION SELECT statement allows the chaining of two separate SQL SELECT queries that have nothing in common. For example, consider the following SQL query:

SELECT ProductName, ProductDescription  FROM Products  WHERE ProductID = '123' UNION SELECT Username, Password FROM Users; 

The result of this query is a table with two columns, containing the results of the first and second queries, respectively. An attacker may use this type of SQL injection by requesting the following URL:

http://www.mydomain.com/products/products.asp?productid=123 UNION  SELECT user-name, password FROM USERS 

The security model used by many Web applications assumes that an SQL query is a trusted command. This enables attackers to exploit SQL queries to circumvent access controls, authentication and authorization checks. In some instances, SQL queries may allow access to host operating system level commands. This can be done using stored procedures. Stored procedures are SQL procedures usually bundled with the database server. For example, the extended stored procedure xp_cmdshell executes operating system commands in the context of a Microsoft SQL Server. Using the same example, the attacker can set the value of ProductID to be "123;EXEC master..xp_cmdshell dir--", which returns the list of files in the current directory of the SQL Server process.

Prevention

The most common way of detecting SQL injection attacks is by looking for SQL signatures in the incoming HTTP stream. For example, looking for SQL commands such as UNION, SELECT or xp_. The problem with this approach is the very high rate of false positives. Most SQL commands are legitimate words that could normally appear in the incoming HTTP stream. This will eventually case the user to either disable or ignore any SQL alert reported. In order to overcome this problem to some extent, the product must learn where it should and shouldn't expect SQL signatures to appear. The ability to discern parameter values from the entire HTTP request and the ability to handle various encoding scenarios are a must in this case.

Imperva SecureSphere does much more than that. It observes the SQL communication and builds a profile consisting of all allowed SQL queries. Whenever an SQL injection attack occurs, SecureSphere can detect the unauthorized query sent to the database. SecureSphere can also correlate anomalies on the SQL stream with anomalies on the HTTP stream to accurately detect SQL injection attacks.

Another important capability that SecureSphere introduces is the ability to monitor a user's activity over time and to correlate various anomalies generated by the same user. For example, the occurrence of a certain SQL signature in a parameter value might not be enough to alert for SQL injection attack but the same signature in correlation with error responses or abnormal parameter size of even other signatures may indicate that this is an attempt at SQL injection attack.

Cross-Site Scripting (XSS or CSS)

Cross-Site Scripting

Cross-site scripting ('XSS' or 'CSS') is an attack that takes advantage of a Web site vulnerability in which the site displays content that includes un-sanitized user-provided data. For example, an attacker might place a hyperlink with an embedded malicious script into an online discussion forum. That purpose of the malicious script is to attack other forum users who happen to select the hyperlink. For example it could copy user cookies and then send those cookies to the attacker.

Details

Web sites today are more complex than ever and often contain dynamic content to enhance the user experience. Dynamic content is achieved through the use of Web applications that can deliver content to a user according to their settings and needs.

While performing different user customizations and tasks, many sites take input parameters from a user and display them back to the user, usually as a response to the same page request. Examples of such behavior include the following.

  • Search engines which present the search term in the title ("Search Results for: search_term")
  • Error messages which contain the erroneous parameter
  • Personalized responses ("Hello, username")

Cross-site scripting attacks occur when an attacker takes advantage of such applications and creates a request with malicious data (such as a script) that is later presented to the user requesting it. The malicious content is usually embedded into a hyperlink, positioned so that the user will come across it in a web site, a Web message board, an email, or an instant message. If the user then follows the link, the malicious data is sent to the Web application, which in turn creates an output page for the user, containing the malicious content. The user, however, is normally unaware of the attack, and assumes the data originates from the Web server itself, leading the user to believe this is valid content from the Web site.

For example, consider a Web application that requires users to log in to visit an authorized area. When users wish to view the authorized area, they provide their username and password, which is then checked against a user database table. Now, assume that this login system contains two pages: Login.asp, which created a form for the users to enter their username and password; and the page CheckCredentials.asp, which checks if the supplied username/password are valid. If the username/password are invalid, CheckCredentials.asp uses (for example), a Response.Redirect to send the user back to Login.asp, including an error message string in the query string . The Response.Redirect call will be something like the following.

Response.Redirect("Login.asp?ErrorMessage=Invalid+username+or+password") 

Then, in Login.asp, the error message query string value would be displayed as follows:

Using this technique, when users attempt to login with an invalid username or password, they are returned to Login.asp and a short message is displayed indicating that their username/password were invalid. By changing the ErrorMessage value, an attacker can embed malicious JavaScript code into the generated page, causing execution of the script on the computer of the user viewing the site. For example, assume that Login.asp is being called using the following URL.

http://www.somesite.com/Login.asp?ErrorMessage=

As in the code for Login.asp, the ErrorMessage query string value will be emitted, producing the following HTML page:

The attacker embedded HTML code into this page in such a way that when users browse this page, their supplied username and password are submitted to the following page.

http://www.hax0r.com/stealPassword.asp 

An attacker can send a link to the contrived page via an email message or a link from some message board site, hoping that a user will click on the link and attempt to login. Of course, by attempting to login, the user will be submitting his username and password to the attacker's site.

Prevention

Cross-site scripting is one of the easiest attacks to detect, yet many Intrusion Prevention Systems fail to do so. The reason why cross-site scripting can be easily detected is that unlike most application level attacks, cross-site scripting can be detected using a signature. The simple text pattern

To accurately detect cross-site scripting attacks the product must know where and when to look for that signature. Most cross-site scripting attacks occur either with error pages or with parameter values. Therefore the product needs to look for cross-site scripting signatures either within parameter values or within requests that return error messages. To look for signatures in parameters values the product must parse the URL correctly and retrieve the value part and then search for the signature on the value while overcoming encoding issues. To look for signatures in pages that return error messages the product needs to know that the specific URL returned an error code. Intrusion Detection and Prevention Systems which are not Web application oriented simply do not implement these very advanced capabilities.

Monday

The Test Lead is inexperienced, is 'stealing' your work and is taking away all the credit. What is the best way to avoid frustration and deal with?

Tip of the day : Finding a software Testing Job

here are many people who would like to get software testing jobs, but they are unsure about how to approach it. This may seem like a dream j...