RSSComputers / Programming / Mobiles (73)

11-08-2016 Write arabic script shortcut, presentation in MsOffice and HTML
21-06-2014 Meet the Pakistani who is reinventing the Internet. Well kind of...
19-02-2014 Collection of e-Books and Articles on Microsoft Technologies
26-03-2013 Restore SharePoint backup from earlier to later version - Your backup is from a different version of Microsoft SharePoint Foundation and cannot be restored to a server running the current version
21-12-2012 Air bags for electronics devices
08-11-2012 Recursive Query Parent Child Concatenation
25-04-2012 Change or remove filter / filter content from Sharepoint list / library view columns
23-02-2012 Pakistani IT experts win international cyber drill
26-12-2011 Installing XP on computer with SATA hard drive
20-04-2011 Sigin as different user in using Windows authentication
26-01-2011 Powershell CmdLets
30-05-2010 Update Statistics - Query to find tables and index number of statistics being old
15-04-2010 Detail Error Message for ASP.NET at Web Hosting / Production server
15-03-2010 Passing encrypted data between JavaScript and C#
12-02-2010 Sharepoint - SPWeb.Groups Vs SPWeb.SiteGroups
28-01-2010 Accessing JD Edwards Data on iSeries or AS/400 from a ASP.NET / SQL Encoding / Error problem
28-01-2010 Controls not functional after Export to Excel or Export to PDF of Telerik in Sharepoint Application page
05-10-2009 ASP.NET Cannot open log for source {0}. You may not have write access. - Access is denied
03-09-2009 Turn off Reading pane / Auto Preview for all folders in Outlook
28-08-2009 CRM - The SELECT permission was denied on the object 'BuildVersion', database 'MicrosoftCRM_MSCRM', schema 'dbo'
25-08-2009 CRM - No authority could be contacted for authentication (Report Server)
22-08-2009 CRM - Retrieve Cultures information from CRM into your Custom Web Application
21-08-2009 CRM - Globalization / Localization in Custom Web Application
19-08-2009 CRM - Do you want to save this file? Blank.aspx?
18-08-2009 CRM Exception - Microsoft.Crm.Application.Platform.Report. InternalCreate(String xml)
18-08-2009 CRM Exception - Microsoft.Crm.Reporting.SRSReport.convertDataSource()
03-08-2009 Locale ID (LCID) Chart
24-06-2009 Oracle SQL Developer - Unable to create an instance of the Java Virtual Machine
17-06-2009 Busy at work
17-06-2009 Boss Menu
10-04-2009 Facebook Privacy Setting - Applications
18-03-2009 For a Software House
27-01-2009 Clock ticking on worm attack code
27-01-2009 Detecting Idle time or Inactivity in Windows Forms
27-01-2009 Values of Windows API
23-01-2009 PasswordChar and Set focus on page load for ToolStripTextBox
21-01-2009 Capture Form Close Event
21-01-2009 Richtextbox or multiline textbox and AcceptButton to handle Enter or Tab key press
21-01-2009 Key Combination shortcuts in C# Windows Form
01-01-2009 Application Architecture Guide 2 patterns and practices
01-01-2009 Convert string to hexadecimal and hexadecimal to string
31-12-2008 Implementing Transaction in Stored Procedure
31-12-2008 Implementing Transaction in .NET
25-12-2008 Linux environment in Windows
11-12-2008 Facebook Privacy Setting
27-11-2008 Pakistani group hacks Indian websites - Cyber Attack
26-10-2008 Designations...funny!
16-10-2008 Securing Your ASP.NET Web Applications
15-10-2008 Software blocks car phone users
07-10-2008 Too much in technology!
14-09-2008 Logo Evolution
13-09-2008 Difference between .NET 2.0/3.0/3.5
03-09-2008 Google launches internet browser
27-08-2008 Excel Shortcuts
16-07-2008 Quantum information technology - Enigma variations
04-07-2008 Dead Lock - Boss and Secratory
04-07-2008 Web Service Security using SOAP Extension
24-06-2008 General Web Security Consideration
24-06-2008 ASP.NET Forms Authentication
20-06-2008 Find rowcount, columncount, table size in Sql Server Database
20-06-2008 Developers
19-06-2008 Windows Shortcuts
18-06-2008 Number of Microsoft Certified Professionals Worldwide
16-06-2008 Types of developers
22-05-2008 documentary on Google
12-05-2008 Moonlight (Silverlight for Linux)
24-04-2008 Take Advantage of ASP.NET Built-in Features to Fend Off Web Attacks
01-04-2008 Health, Calculator , Units Conversion All in One. Very useful to all
28-02-2008 General Motors vs. Bill Gates
16-02-2008 Stealth Deployment
14-02-2008 Resignation letter of a Software Employee
12-02-2008 Development
05-05-2007 Knowledge
Wed 31 Dec 2008

Today I need to implement transaction in .NET. Front end language was VB.NET and database was Oracle.

This transaction is being implemented using Oracle Data Access Provider - ODP.NET.

Simple implementation is that create and open a connection, begin transaction using that connection, create command using that connection, call stored procedures or statments using command(s), if every thing gone fine and success then call commit of that transaction else rollback, and in last close and dispose connection and transaction.

Be sure not to use commit, rollback or statement that causes transaction invalidate inside the procedure that is being called within .NET transaction, otherwise that .NET transaction scope will no longer valid as within that connection commit or rollback have been called.

Sample code that make my work done is :-


Private Sub Save()
Dim conn As New OracleConnection("ConnString")
Dim trans As OracleTransaction
Dim success as Boolean = False

 trans = conn.BeginTransaction
success =  saveThingOne(conn)
If success Then
success = saveThingTwo(conn)
End If

If success  Then
End If

Catch ex As Exception
End Try
End Sub

Private Sub saveThingOne(ByVal conn As OracleConnection) As Boolean
Dim success as Boolean = False
Using comm As New OracleCommand("Save_Thing_One_Stored_Procedure", conn)
   comm.CommandType = CommandType.StoredProcedure
   comm.Parameters.Add("IN_ID", OracleType.Number).Value = intID
   comm.Parameters.Add("IN_THING_ONE", OracleType.VarChar, 60).Value = strThingONe
   comm.Parameters.Add("OUT_RESULT", OracleType.Number).Direction = ParameterDirection.Output
‘Here if that procedure successfully perform action then will return 0 in case of success and 1 in case of failure
success = Iif(comm.Parameters(“OUT_RESULT”).Value.ToString().equals(“0”), True, False)
Return success
End Using
End Sub

Private Sub saveThingTwo(ByVal conn As OracleConnection)
Dim success as Boolean = False
Using comm As New OracleCommand("Save_Thing_Two_Stored_Procedure", conn)
   comm.CommandType = CommandType.StoredProcedure
   comm.Parameters.Add("IN_ID", OracleType.Number).Value = intID
   comm.Parameters.Add("IN_THING_TWO", OracleType.VarChar, 60).Value = strThingTwo
   comm.Parameters.Add("OUT_RESULT", OracleType.Number).Direction = ParameterDirection.Output
‘Here if that procedure successfully perform action then will return 0 in case of success and 1 in case of failure
success = Iif(comm.Parameters(“OUT_RESULT”).Value.ToString().equals(“0”), True, False)
Return success

End Using
End Sub



E-mail this post to someone or Comments here
Thu 11 Dec 2008

Being a facebook developer, following information will be helpful for users.

Privacy is always an important factor in personal life and behaving.

If any female or male doesn't want to share his or her photos or albums on facebook with unknown personals, which are vulnerable to misbehavers, then don't forget to set its privacy setting at following locations :-  Click on

1) Settings (from top facebook menu -> Privacy Setting -> Profile -> Edit Photo Albums Privacy Settings

2) Settings (from top facebook menu -> Privacy Setting -> Profile -> Photo Tagged of You

You may set its value of who can see this to Only Friends or Lower Custom Settings.

Are you sure you want to share your photos and personal information to persons who you dont know and to strangers?, If no then set your privacy settings now!



facebook privacy setting 1.jpg



 facebook privacy setting 4.JPG




facebook privacy setting 2.JPG


facebook privacy setting 3.JPG


For Facebook privacy settings - applications, click following link

E-mail this post to someone or Comments (3)
Thu 27 Nov 2008

KARACHI: In what seems to be an intensifying cyber war between hackers of Pakistan and India, Pakistani hackers managed to hack website of ONGC (Oil and Natural Gas Corporation) of India on Tuesday.

A group named ‘Pakistan Cyber Army’ (PCA) said that it hacked Indian ONGC website in response to hacking of the website of Pakistan’s OGRA (Oil and Gas Regulatory Authority) by Indian hackers.

Sites hacked among are CID Andhra Pardesh India, India Rail, Indian ONGC.

 Reference :


E-mail this post to someone or Comments here
Sun 26 Oct 2008

IT Designations

Wonderful definitions of IT designations at office.

1) Project Manager is a Person who thinks Nine women can deliver a baby in One month.
2) Developer is a Person who thinks it will take 18 months to deliver ababy.
3) Onsite Coordinator is one who thinks single woman can deliver nine babiesin one month.
4) Client is the one who doesn't know why he wants a baby.
5) Marketing Manager is a person who thinks he can deliver a baby even if no man and woman are available.
6) Resource Optimization Team thinks they don't need a man or woman; they'llproduce a child with zero resources.
7) Documentation Team thinks they don't care whether the child is delivered, they'll just document 9 months.
8) Quality Auditor is the person who is never happy with the PROCESS to produce a baby


E-mail this post to someone or Comments (1)
Thu 16 Oct 2008


Web application security is not just about attackers hacking websites, stealing sensitive information from websites, sending high traffic to websites with denial of service attacks, viruses, worms and Trojan horses. Are these are the only problems that we have? The answer is no. There are other problems that are frequently overlooked.

The objective of this article is to give you an insight on various areas that a design architect should focus on while designing a web application to make more secured. This article discusses almost all types of vulnerability that can be exploited by the hacker and the counter measure to avoid the same.

Effective way of analyzing the various security issues on a web application by decomposing the problem domain into various areas of focus. I have discussed the same in detail below. If you follow this approach, you get your focus on the key design and implementation choices that affect your application's security.

Input validation

Identifying the validation needs for type, length, format or range of input data avoids hacker discovering the vulnerability in your application. An attacker can compromise your application if any such vulnerability is identified. It is a must to validate the input before processing it by your application. So, how do you know that your application is safe enough? You just need to answer whether your application trusts the input blindly. If the answer is yes, may be your application is susceptible for following threats.

  • Buffer Overflow
  • Cross-site scripting
  • SQL injection
  • Canonicalization

Buffer Overflow

This vulnerability leads to denial of service attacks and it eventually leads to process crash. Another vulnerability of buffer overflow is code injection which eventually alters the program execution address to run an attacker's injected code. The following piece of code demonstrates the example for occurrence of buffer overflow.

// Vulnerable function
void vulnerable(char *str)
char buffer[10];
strcpy(buffer, str);
// overrun buffer !!!
int main()
// declare buffer that is bigger than expected
char large_buffer[] = "This string is longer than 10 characters!!!";

Managed .NET code is not susceptible to this problem because array bounds are automatically checked whenever an array is accessed. It is still a concern, however, especially where managed code calls unmanaged APIs or COM objects.

Countermeasures to prevent buffer overflows

  • Perform thorough input validation
  • Wherever possible, limit application's use of unmanaged code
  • If unmanaged API is called in your application, check the values passed for the parameters of unmanaged API to avoid this attack
  • Compile your code with /GS flag if it is developed in Microsoft Visual C++ system. The /GS option detects some buffer overruns, which overwrite the return address - a common technique for exploiting code that does not enforce buffer size restrictions. This is achieved by injecting security checks into the compiled code.

Cross-site scripting

It is commonly referred as XSS occurs when a web application gathers malicious data from a user. Often attackers will inject JavaScript, VBScript, ActiveX, HTML, or Flash into a vulnerable application to fool a user in order to gather data from them.

Because the script code is downloaded by the browser from a trusted site, the browser has no way of knowing that the code is not legitimate. Internet Explorer security zones provide no defense. Since the attacker's code has access to the cookies associated with the trusted site and are stored on the user's local computer, a user's authentication cookies are typically the target of attack.

Attacker normally exploits this by identifying the vulnerable page that outputs the unvalidated input back to the browser. The following snippet of code shows the input that is accepted a vulnerable page that exploits this vulnerability<script>alert('Your page is hacked')</script>

When this link is clicked, it will show an alert message because of the script tag embedded in the url. The legitimate url is suppose to carry the original user name which can be exploited as above

Counter measure to prevent XSS

  • Perform thorough input validation on form fields, query strings, cookies. Always check for scripting tags and filter the same. Regular expression is the best way of validating input
  • User inputs should be encoded using HTMLEncode and URLEncode functions

SQL Injection

Using this attack, the attacker can run the code of his choice in the database. The same will be achieved by exploiting the unvalidated input. Typical scenarios where this could be exploited are application that constructs dynamic SQL statements based on the user input and application that executes stored procedure with arguments based on the user input. The attacker can go to a maximum extent of running operating system commands if the account under which the SQL statements executed were over privileged. The extent to which the data being destroyed, manipulated and retrieved is based on the privilege of the account under which the SQL command is being executed.

Following snippet of code shows how this vulnerability can be exploited.
SqlDataAdapter myCommand = new SqlDataAdapter("select * from tablename where fieldname = '" + userinput + "'", myConnection);
The above code gets executed based on the user input. This code can be exploited if the input is entered/passed as value'; Any valid SQL command

Counter measures to prevent SQL Injection

  • Validate the input received by the application using regular expression
  • Set appropriate privileges to execute the SQL commands
  • Stored procedures executed using arguments should be parameterized stored procedures


When the different forms of input accepted resolves a standard name otherwise called canonical name, it is referred to as canonicalization. The application code is susceptible to canonicalization related issues when it makes a security decision based on the name of a resource that has been received as input. Files, paths and URLs are susceptible for this vulnerability.

A single file can be represented in many different ways as shown below

Countermeasures to prevent this vulnerability

  • Avoid accepting file name as input. When there is a need for accepting input to grant access, convert the name to canonical form prior providing security decisions
  • Assure well formed filenames are received and check whether they are within your application's directory hierarchy
  • Ensure that the character encoding is set correctly to limit how input can be represented. Check that your application's Web.config has set the requestEncoding and responseEncoding attributes on the <globalization> element.


Authentication is the act of validating the user to whom s/he claims to be. .NET framework has provided several authentication mechanisms that user can choose upon and implement in the application. An attacker can find a vulnerability if they are not properly implemented. Following are the possible vulenerabilities that an attacker can find in improper implementation

  • Network eavesdropping
  • Brute force attacks
  • Dictionary attacks
  • Cookie replay attacks
  • Credential theft

Network eavesdropping

This can be exploited only when passwords are passed in plain text format from client to server. This is accomplished by using network monitoring software that can capture traffic leading to host which is on the same network.

Countermeasure to prevent eavesdropping

  • Use Kerberos authentication or Windows authentication which doesn't transmit the password over the network
  • When there is a necessity for transmitting password through network, use an encryption communication channel like SSL which will encrypt the contents passed through network channel

Brute force attacks

Hacking the sensitive data like password or other such secrets by relying upon the computational power to identify the hash string and encryption technique used for securing the sensitive information.

Countermeasure to prevent Brute force attacks

  • The only way is by using a very strong hash key strings

Dictionary attacks

Typically, sensitive information like password will not be stored in plain text format or encrypted form in the application. Rather the application normally uses a hashing technique and stores the hashed strings. If an attacker gains the access to hash strings stored in the application, a dictionary attack can be performed. That is, iterate through all the words in a dictionary of all possible languages to arrive to the hashed string retrieved by the attacker.

Countermeasure to prevent dictionary attacks

  • Use strong passwords with that are complex. Use mixture of uppercase, lowercase, numerals, special characters in the password that makes difficult to crack.
  • Store non-reversible password hashes in the user store. Also combine a salt value (a cryptographically strong random number) with the password hash.

Cookie replay attacks

The attacker can read authentication information that is submitted for the application to gain access. The attacker can then replay the same information to the application causing cookie replay attacks

Countermeasure to prevent cookie replay attacks

  • Use SSL that encrypts al the information including cookie information passed through the channel
  • Always use timeout property for the cookie information. This will reduce the probability of attack.

Credentials theft

If your application implements its own user store containing user account names and passwords, compare its security to the credential stores provided by the platform, for example, a Microsoft Active Directory directory service or Security Accounts Manager (SAM) user store. Browser history and cache also store user login information for future use. If the terminal is accessed by someone other than the user who logged on, and the same page is hit, the saved login will be available

Countermeasures to prevent credential theft

  • Use and enforce strong passwords
  • Store password verifiers with one way hash with added salt
  • Enforce account lockout for end-users after a set number of retry attempts
  • Set the expiry property for the content rendered in the browser or force the browser not to cache the information


Authorization is all about granting or denying access to the resource for which access is requested by the user. It will be accomplished based on user identity and role membership. Top threats that exploit authorization are

  • Elevation of privilege
  • Disclosure of confidential data
  • Data tampering
  • Luring attacks

Elevation of privilege

An attacker trying to elevate privileges to become a member of the local administrator group or local system account by calling the RevertToSelf API referred as Elevation of privilege. This will enable the attacker to take complete control over application and local machine.

Counter measure to prevent elevation of privilege

  • While designing the system, ensure that application gains access only to least privileged process, services and user accounts.

Disclosure of confidential data

Unauthorized users gaining access to sensitive data is referred as disclosure of confidential data. Confidential information should be secured in persistent store like databases, xml files and other configuration files. Care should be taken while transmitting the information through the network. Access to system level configuration data should be restricted to administrators

Counter measure to prevent disclosure of confidential data

  • Before providing access to sensitive data perform a role check
  • Always secure windows resources using strong Access Control Lists (ACL)
  • Persistent stores like database and configuration files should store the sensitive information in the encrypted form

Data tampering

Data tampering refers to unauthorized modification of data. An attacker, who gains access to the information transmitted through the network, can modify the information and the application while receiving will get the tampered data.

Countermeasures to prevent data tampering

  • Always secure windows resources using strong Access Control Lists (ACL)
  • Use role-based security to differentiate between users who can view data and users who can modify data.

Luring Attacks

A luring attack occurs when an entity with few privileges is able to have an entity with more privileges perform an action on its behalf.

Countermeasures to prevent luring attacks

  • Restrict access to trusted code with appropriate authorization. Code access security (CAS) of .NET framework can be used whenever a request is made to secure resources

Configuration management

Many applications provide configuration management interfaces and functionality to allow operators and administrators to change configuration parameters, update web site content, and to perform routine maintenance. If these interfaces were carefully not designed, it could lead following threats

  • Unauthorized access to administration interfaces
  • Unauthorized access to configuration stores
  • Retrieval of plain text configuration secrets
  • Lack of individual accountability
  • Over-privileged process and service accounts

Unauthorized access to administration interfaces

Most of the web applications provide interfaces to administrators, operators and content developers to manage site content and configuration. It should be available only to the restricted users. An attacker who gains access to the configuration management data can bring down the system by altering the configuration data.

Countermeasures to prevent unauthorized access to administrative interfaces

  • Minimize the number of administration interfaces
  • Use strong authentication like using digital certificates or multiple gatekeepers
  • Avoid remote administration interfaces. If it is a must, provide access through VPN or through SSL.

Unauthorized access to configuration stores

Because of the sensitive nature of the data maintained in configuration stores, you should ensure that the stores are adequately secured.

Countermeasures to prevent unauthorized access to configuration stores

  • Configure restricted ACLs on text based configuration files. For e.g. Machine.config and web.config should be configured for restricted access
  • Keep custom configuration files outside the directory that doesn't have web access

Retrieval of plain text configuration secrets

Configuration files such as web.config that stores password or connection string should not store the details in plain text format. External attackers who gains access can then see the sensitive information as it is stored in plain text format. Similarly, disgusted employees and administrators can misuse this sensitive information.

Countermeasure to prevent retrieval of plain text configuration secrets

  • Rather than storing the data in plain text format, store the sensitive information n encrypted formats.

Lack of individual Accountability

It is important to log when the changes were made and who made those changes. If not, it could lead us to a threat of not being able to track the changes made by whom and when. If a malicious change is encountered or any other breaking change is made in the application, corrective action can be taken immediately provided we could identify it from the log.

Countermeasures to prevent Lack of Individual Accountability

  • Administrative accounts must not be shared
  • While using user/application/service accounts, ensure that any damage to the privileges using this account can be identified
  • Apply preventive measures for all the possible violation that you foresee

Over-privileged process and service accounts

There might be a need for an application or service account to change the configuration information on the system. An attacker can take advantage of the same to modify configuration information.

Countermeasures to prevent over-privileged process and service accounts

  • Avoid providing rights to change the configuration information unless it is mandatory. In that case, enable auditing and logging to track each and every change made by the account.

Sensitive Data

Sensitive data is always at great risk as attackers try to view or modify sensitive information from the persistent data storage and networks. It is subjected to variety of threats by the attackers. Often, they are

  • Access to sensitive data in storage
  • Network eavesdropping
  • Data tampering

Access to sensitive data in storage

When the data is stored in a persistent data stores, action should be taken to prevent the attacker from gaining access to the data store. That is the attacker should not be able to either view or modify the information.

Countermeasures to protect access to sensitive data in storage

  • Use Access Control Lists to ensure that required users alone are provided with rights to view or modify the information stored in data storage
  • Always store the sensitive data in encrypted format. Never store it in a plain text format
  • Differentiate view and modify operations separately and provide access accordingly. Use identity and role based authorization to achieve the same.

Network Eavesdropping

In a web application, an http requests and responses travel through the network is sent in a plain text format. An attacker can use network monitoring tool to capture the information sent in the network and can even modify the information sent in the network

Countermeasures to prevent network eavesdropping

  • Use encryption for sensitive data so that it will not be sent in a plain text format when it is transmitted through the network
  • If required, consider encrypting the communication channel by implementing SSL

Data tampering

Data tampering refers to unauthorized modification of data. When sensitive data is passed in plain text format through the network, information can be modified resulting in tampered information reaching the destination.

Countermeasure to prevent Data tampering

  • Use tamper resistant protocols such as hashed message authentication codes.

Session Management

Sometimes application stores sensitive information in the session objects. Session objects should be managed by application layer. However, storing sensitive information in the session objects leads to potential threats. They include

  • Session Hijacking
  • Session Replay
  • Man in the middle

Session Hijacking

In most of the applications, the authentication is stored in a cookie for a particular user's session. An attacker can use a network monitoring tool to capture this information. Having captured the authentication token, an attacker can spoof the user's session and gain access to the system. An attacker can perform all the operations as that of legitimate user.

Countermeasures to prevent session hijacking

  • Avoid storing anything in the session objects. However, if the application demands that then use the following prevention technique
  • Implement SSL as it will encrypt all the information that is transmitted via the network. In that case, the authentication token stored in the cookie too will be encrypted and sent via the communication channel.
  • Allow only one session per user at a time. If a new session is started for the same user, implement logout functionality.
  • Incase if SSL is not implemented and still there is a need to store information in the session object, ensure you set a time period for expiry. Though it doesn't prevent the user from session hijacking, it reduces the risk of attack when the user is attempting for stealing cookie information.

Session Replay

If an attacker gains access to the authentication token stored in a cookie, then the attacker can then frame a requests with the authentication cookie received from another user to the application from which the authentication cookie is sent. An attacker gets access to the system as that of legitimate user.

Countermeasures to prevent session replay

  • Do not store authentication information on the client
  • Whenever a critical function is being called or an operation is performed, re-authenticate the user
  • Set expiry date for all cookies

Man in the middle attacks

When communication happens between sender and receiver, an attacker can come in the middle and intercept all the messages transmitted between the sender and receiver. An attacker can then change the information and send it to receiver. Both sender and receiver will be communicating with each other without the knowledge of a man in the middle who intercepts and modifies the information.

Countermeasures to prevent man in the middle attacks

  • Use strong encryption. When the data is sent in a encrypted format, even though the man in the middle gains access to the information, s/he will not be able to intercept the original message as it is encrypted
  • Use Hashing. When attacker tries to modify the hashed information, recalculation of hash will not be successful and hence it can be discovered that the information is modified in the middle.


Applications use cryptography to store sensitive information and transmit sensitive information across the network. However, if an attacker gains access to encrypted information, attacker should not be able to decrypt to the original information. When encryption information, common threats that it can lead to are

  • Poor key generation or key management
  • Weak or custom encryption

Poor key generation or key management

An attacker can decrypt to original information, if they get access to either encryption key or they can intercept or arrive to encryption key from the encrypted information. Attacker can identify this key only if they are poorly managed or they were not generated in a random fashion.


  • Use built-in encryption routines that include secure key management. Data Protection application programming interface (DPAPI) is an example of an encryption service provided on Windows 2000 and later operating systems where the operating system manages the key.
  • Use strong random key generation functions and store the key in a restricted location - for example, in a registry key secured with a restricted ACL - if you use an encryption mechanism that requires you to generate or manage the key.
  • Encrypt the encryption key using DPAPI for added security.
  • Expire keys regularly

Weak or Custom encryption

When users define their own encryption algorithm, it has to be properly tested. Weak encryption algorithms are easy to break. Users should go for well known encryption algorithms that are been used for long time. If there is a need for using custom encryption algorithm, it has to be properly tested.

Countermeasures to address weak or custom encryption

  • Avoid using custom encryption algorithms
  • Use the well known encryption algorithm that are been in use for longtime that withstood against all attacks
  • Be aware of algorithms that are cracked and techniques used to crack them

Parameter Manipulation

In web application, communication that happens through http protocol between client and server is transmitted as a plain text over the network. Information captured from the user is either sent in the form of query string, form fields, cookies and HTTP headers in the communication channel. These parameter data are sent as a plain text through the channel and attackers can manipulate these data before it reaches the server. This leads to following major threats that needs to be taken care

  • Query String manipulation
  • Form field manipulation
  • Cookie manipulation
  • HTTP header manipulation

Query String manipulation

When user information is sent through query string, it would be clearly visible to the user as the query string information is appended with the URL address and sent to the server. If the security mechanism of your application relies on the query string values to check the user credentials or any other security decisions are taken based on that, the application is vulnerable to security attack.

Countermeasures to address query string manipulation

  • Do not pass security related information through query string
  • Use encryption to send the information passed via query string
  • Use HTTP POST rather than using HTTP GET.

Form field manipulation

As the HTTP Protocol transmits the information in plain text, it is still possible for the attackers to modify any form fields and their values that are sent to the server. So, do not rely on the hidden fields for passing security credentials as it can be modified bypassing the client script validations.

Countermeasures to address form field manipulation

  • Use session identifiers to reference state maintained in the state store on the server.

Cookie manipulation

Cookie manipulation does refer to modification of cookie values that are of both persistent cookies and memory resident cookies. If cookie value stores information used for security mechanism of the application, the application is vulnerable to attack.

Countermeasures to address cookie manipulation

  • Use SSL which encrypts the information that are transmitted via the communication channel
  • Incase of persistent cookies stored in the client computer, use encryption or hashing to protect the information

HTTP Header manipulation

In web application, the client always makes request through HTTP protocol and the server responses through HTTP Protocol. During submitting the requests, client prepares the request HTTP headers and during response, server prepares the response HTTP headers. Application should not make any security decisions based on request and response headers. If so, the application is vulnerable to attack.

Countermeasures to HTTP Header manipulation

  • Do not use HTTP Headers to make security decisions

Exception Management

When exceptions are thrown from the application, sometimes the information shown in the exception might not be making sense for the end user but might be a very interesting message for an attacker. Especially, when it reveals the internals of the underlying system. While handling all types of exception is very important, the message that is shown to the user is also equally important. If not it leads to threats that includes

  • Attacker reveals implementation details
  • Denial of service

Attacker reveals implementation details

When the exceptions are thrown from the application, it might reveal the SQL information like tables, connection strings, column names, etc… that will become a open door for an attacker to take the entry into the application.

Countermeasures to prevent important information being shown in exception to users

  • Handle all types of exception in your application through out the code base.
  • Log all the exceptions that rose in the application for internal use. However, show appropriate information in the front end to the user who received this exception

Denial of Service

The objective of the attacker is to make application to behave abnormally such that either it reveals internals of the underlying system or crashes the application process such that no other user can use the application. Application crash can occur if the exceptions are not properly caught and handled.

Countermeasures to prevent denial of service

  • Each individual input received from the user should be thoroughly validated
  • Handle all types of exception in your application through out the code base.

Auditing & Logging

Auditing and logging enables to identify whether any one is trying to exploit the application. Any attempt to exploit the application, if logged can help to identify which user is trying to exploit and necessary actions can be taken to prevent the system from such attacks. If not enabled, it is harder to find out whether any one is actually exploiting the system without the system administrator being aware. This could lead to following threats

  • User denies performing an operation
  • Attackers exploit an application without leaving a trace
  • Attackers cover their tracks

User denies performing an operation

To address the issue of repudiation that concerned with user denying that he/she performed an action or initiated a transaction, a defense mechanism should be in place to ensure that all the user activity can be tracked and recorded

Countermeasures to prevent

  • Enable auditing and logging in web server, database server and application server.
  • Identify the key events and log them. For eg. Login, logout events
  • Avoid shared accounts. It will lead to difficulty as we cannot trace out the original source

Attackers exploit an application without leaving a trace

Detection mechanism should be there to identify the suspicious activity that occurs in the system. It should be logged to identify the occurrence of exploit or whether someone is trying to exploit.

Countermeasure to detect such suspicious activities

  • All critical application level operations should be logged
  • Read the log files every day to detect suspicious activity. Always maintain the back up of log files
  • If the platform provides any support to log important transactions, make use of that

Attackers cover their tracks

What if your log file can be tampered? Situation should never be worse like this. So, it should be well protected to ensure that an attacker does the exploit and clean the audit file too.

Countermeasures to prevent

  • Do not keep the log files in the default location folder. Move it to a different location.
  • Secure log files using Access Control Lists


This article contributed by krishnan.rama  August 31, 2004 explained you the doorsteps that attacker takes to exploit your application. Now that you will be aware of the techniques used by attackers. The next step should be protecting your application against all the techniques described above. For more information on security, follow this url


E-mail this post to someone or Comments (1)
Wed 15 Oct 2008

A safety device which prevents drivers using mobile phones by automatically intercepting calls and text messages when they are moving has been unveiled.

The software tells callers the person they are trying to reach is driving and asks them to leave a message.

   Software blocks car phone users _45107516_driver-on-phone-226b.jpg
 start_quote_rb.gif Our advice to drivers is to switch off their mobile phones... and let voicemail do its job end_quote_rb.gif
The Royal Society for the Prevention of Accidents

Canadian firm Aegis Mobility hopes its system will become available via a monthly subscription fee.

The Royal Society for the Prevention of Accidents (RoSPA) says drivers are four times as likely to crash using a phone.

Phone fine

The DriveAssist system can also tell callers where the person they are trying to reach is located by using satellite navigation technology.

Motorists using mobile phones caused 25 fatal, 64 serious and 259 slight accidents in 2007, according to the Department for Transport.

It has been illegal to use a mobile phone while driving since December 2003 - with offenders facing a £60 on-the-spot fine and three points on their licence.

A RoSPA spokesperson told BBC News: "Our advice to drivers is to switch off their mobile phones when they get behind the wheel and let voicemail do its job."

Meanwhile, a survey by motoring group RAC shows almost half of drivers are seriously distracted by in-car technology - rising to 55% for 17-to-24-year-olds.

The most distracting gadgets were radios and CDs, followed by mobile phones and satnav systems which each put off around a third of drivers.

Heating and air conditioning controls distracted 35% in the survey of 1,034 motorists.

Anti-locking brake systems (ABS) and immobilisers are fitted as standard on new cars, yet only 70% of drivers knew they had ABS and only 68% knew they had immobilisers.

The Department for Transport says distractions account for 12% of all road accidents. In 2007 that amounted to 75 fatal, 411 serious and 2,517 slight accidents.

The RAC survey also looked to the next 20 years of motoring and revealed:

 • 23% believe drivers will be able to simply input an end destination then sit back and enjoy the ride.

 • 35% think cars will be able to "talk" to each other to pinpoint and avoid traffic.

 • 71% believe cars will be able to tell you when you are exceeding the speed limit with half predicting automatic prevention.

 • 60% predict fingerprint, voice or breath recognition will replace keys to start a car.

 RAC's technical director David Bizley said: "In-car technology has come a long way since the late 80s. The advances have fallen into two camps - active and passive.

"Active technologies such as in-car entertainment are not always positive as they can cause driver distraction, while passive technologies, such as anti-locking brake systems (ABS), are undervalued as they are not fully understood or deemed less important as they come on automatically."


E-mail this post to someone or Comments here