Wed 19 Aug 2009

If you are getting a popup while navigating through Microsoft Dynamics CRM Application asking you to save Blank.aspx file, following workaround will help you

 

 

Please edit the default blank.aspx file in CRM (Sever where CRM is installed) so it contains data. This file is located at My Computer | System Drive | Program Files | Microsoft Dynamics CRM | CRMWeb |_ root. Here you will find the Blank.aspx text file.

 

Open the file and add some text to the file, for example you can add "Test" to the file (then there would be following three lines)

 

Test

<% Response.Expires = 1440; %>

<% Response.Cache.SetCacheability(HttpCacheability.Public); %>

 

 

 

Once you have added data, save the file, clear your temporary Internet Files, and do an IISreset. Once this is done go back into CRM to verify that this has resolved this issue.

 

 

 

 

E-mail this post to someone or Comments (7)
Mon 3 Aug 2009
Locale ID (LCID) Chart

Updated: August 2009

The following table lists Locale IDs (LCID).

Locale description

Short string

Hexadecimal value

Decimal value

Afrikaans

af

0x0436

1078

Albanian

sq

0x041C

1052

Arabic - United Arab Emirates

ar-ae

0x3801

14337

Arabic - Bahrain

ar-bh

0x3C01

15361

Arabic - Algeria

ar-dz

0x1401

5121

Arabic - Egypt

ar-eg

0x0C01

3073

Arabic - Iraq

ar-iq

0x0801

2049

Arabic - Jordan

ar-jo

0x2C01

11265

Arabic - Kuwait

ar-kw

0x3401

13313

Arabic - Lebanon

ar-lb

0x3001

12289

Arabic - Libya

ar-ly

0x1001

4097

Arabic - Morocco

ar-ma

0x1801

6145

Arabic - Oman

ar-om

0x2001

8193

Arabic - Qatar

ar-qa

0x4001

16385

Arabic - Saudi Arabia

ar-sa

0x0401

1025

Arabic - Syria

ar-sy

0x2801

10241

Arabic - Tunisia

ar-tn

0x1C01

7169

Arabic - Yemen

ar-ye

0x2401

9217

Armenian

hy

0x042B

1067

Azeri - Latin

az-az

0x042C

1068

Azeri - Cyrillic

az-az

0x082C

2092

Basque

eu

0x042D

1069

Belarusian

be

0x0423

1059

Bulgarian

bg

0x0402

1026

Catalan

ca

0x0403

1027

Chinese - China

zh-cn

0x0804

2052

Chinese - Hong Kong SAR

zh-hk

0x0C04

3076

Chinese - Macau SAR

zh-mo

0x1404

5124

Chinese - Singapore

zh-sg

0x1004

4100

Chinese - Taiwan

zh-tw

0x0404

1028

Croatian

hr

0x041A

1050

Czech

cs

0x0405

1029

Danish

da

0x0406

1030

Dutch - Netherlands

nl-nl

0x0413

1043

Dutch - Belgium

nl-be

0x0813

2067

English - Australia

en-au

0x0C09

3081

English - Belize

en-bz

0x2809

10249

English - Canada

en-ca

0x1009

4105

English - Caribbean

en-cb

0x2409

9225

English - Ireland

en-ie

0x1809

6153

English - Jamaica

en-jm

0x2009

8201

English - New Zealand

en-nz

0x1409

5129

English - Phillippines

en-ph

0x3409

13321

English - Southern Africa

en-za

0x1C09

7177

English - Trinidad

en-tt

0x2C09

11273

English - Great Britain

en-gb

0x0809

2057

English - United States

en-us

0x0409

1033

Estonian

et

0x0425

1061

Farsi

fa

0x0429

1065

Finnish

fi

0x040B

1035

Faroese

fo

0x0438

1080

French - France

fr-fr

0x040C

1036

French - Belgium

fr-be

0x080C

2060

French - Canada

fr-ca

0x0C0C

3084

French - Luxembourg

fr-lu

0x140C

5132

French - Switzerland

fr-ch

0x100C

4108

Gaelic - Ireland

gd-ie

0x083C

2108

Gaelic - Scotland

gd

0x043C

1084

German - Germany

de-de

0x0407

1031

German - Austria

de-at

0x0C07

3079

German - Liechtenstein

de-li

0x1407

5127

German - Luxembourg

de-lu

0x1007

4103

German - Switzerland

de-ch

0x0807

2055

Greek

el

0x0408

1032

Hebrew

he

0x040D

1037

Hindi

hi

0x0439

1081

Hungarian

hu

0x040E

1038

Icelandic

is

0x040F

1039

Indonesian

id

0x0421

1057

Italian - Italy

it-it

0x0410

1040

Italian - Switzerland

it-ch

0x0810

2064

Japanese

ja

0x0411

1041

Korean

ko

0x0412

1042

Latvian

lv

0x0426

1062

Lithuanian

lt

0x0427

1063

F.Y.R.O. Macedonia

mk

0x042F

1071

Malay - Malaysia

ms-my

0x043E

1086

Malay – Brunei

ms-bn

0x083E

2110

Maltese

mt

0x043A

1082

Marathi

mr

0x044E

1102

Norwegian - Bokml

no-no

0x0414

1044

Norwegian - Nynorsk

no-no

0x0814

2068

Polish

pl

0x0415

1045

Portuguese - Portugal

pt-pt

0x0816

2070

Portuguese - Brazil

pt-br

0x0416

1046

Raeto-Romance

rm

0x0417

1047

Romanian - Romania

ro

0x0418

1048

Romanian - Republic of Moldova

ro-mo

0x0818

2072

Russian

ru

0x0419

1049

Russian - Republic of Moldova

ru-mo

0x0819

2073

Sanskrit

sa

0x044F

1103

Serbian - Cyrillic

sr-sp

0x0C1A

3098

Serbian - Latin

sr-sp

0x081A

2074

Setsuana

tn

0x0432

1074

Slovenian

sl

0x0424

1060

Slovak

sk

0x041B

1051

Sorbian

sb

0x042E

1070

Spanish - Spain (Traditional)

es-es

0x040A

1034

Spanish - Argentina

es-ar

0x2C0A

11274

Spanish - Bolivia

es-bo

0x400A

16394

Spanish - Chile

es-cl

0x340A

13322

Spanish - Colombia

es-co

0x240A

9226

Spanish - Costa Rica

es-cr

0x140A

5130

Spanish - Dominican Republic

es-do

0x1C0A

7178

Spanish - Ecuador

es-ec

0x300A

12298

Spanish - Guatemala

es-gt

0x100A

4106

Spanish - Honduras

es-hn

0x480A

18442

Spanish - Mexico

es-mx

0x080A

2058

Spanish - Nicaragua

es-ni

0x4C0A

19466

Spanish - Panama

es-pa

0x180A

6154

Spanish - Peru

es-pe

0x280A

10250

Spanish - Puerto Rico

es-pr

0x500A

20490

Spanish - Paraguay

es-py

0x3C0A

15370

Spanish - El Salvador

es-sv

0x440A

17418

Spanish - Uruguay

es-uy

0x380A

14346

Spanish - Venezuela

es-ve

0x200A

8202

Southern Sotho

st

0x0430

1072

Swahili

sw

0x0441

1089

Swedish - Sweden

sv-se

0x041D

1053

Swedish - Finland

sv-fi

0x081D

2077

Tamil

ta

0x0449

1097

Tatar

tt

0X0444

1092

Thai

th

0x041E

1054

Turkish

tr

0x041F

1055

Tsonga

ts

0x0431

1073

Ukrainian

uk

0x0422

1058

Urdu

ur

0x0420

1056

Uzbek - Cyrillic

uz-uz

0x0843

2115

Uzbek – Latin

uz-uz

0x0443

1091

Vietnamese

vi

0x042A

1066

Xhosa

xh

0x0434

1076

Yiddish

yi

0x043D

1085

Zulu

zu

0x0435

1077

E-mail this post to someone or Comments here
Thu 1 Jan 2009

 Microsoft Application Architecture Guide 2.0‏.  Nice stuff for those who are interested in Application architecture at http://www.codeplex.com/AppArchGuide

Summary :

Parts

Part I, Fundamentals
Part II, Design
Part III, Layers
Part IV, Archetypes

Forewords

*   Foreword by S. Somasegar

*   Foreword by Scott Guthrie

Chapters

*   Introduction

*   Architecture and Design Solutions At a Glance

*   Fast Track

Part I, Fundamentals

*   Chapter 1 - Fundamentals of Application Architecture

*   Chapter 2 - .NET Platform Overview

*   Chapter 3 - Architecture and Design Guidelines

Part II, Design

*   Chapter 4 - Designing Your Architecture

*   Chapter 5 - Deployment Patterns

*   Chapter 6 - Architectural Styles

*   Chapter 7 - Quality Attributes

*   Chapter 8 - Communication Guidelines

Part III, Layers

*   Chapter 9 - Layers and Tiers

*   Chapter 10 - Presentation Layer Guidelines

*   Chapter 11 - Business Layer Guidelines

*   Chapter 12 - Data Access Layer Guidelines

*   Chapter 13 - Service Layer Guidelines

Part IV, Archetypes

*   Chapter 14 - Application Archetypes

*   Chapter 15 - Web Applications

*   Chapter 16 - Rich Internet Applications (RIA)

*   Chapter 17 - Rich Client Applications

*   Chapter 18 - Services

*   Chapter 19 - Mobile Applications

*   Chapter 20 - Office Business Applications (OBA)

*   Chapter 21 - SharePoint Line-Of-Business (LOB) Applications

Appendix

*   Cheat Sheet - patterns & practices Pattern Catalog

*   Cheat Sheet - Presentation Technology Matrix

*   Cheat Sheet - Data Access Technology Matrix

*   Cheat Sheet - Workflow Technology Matrix

*   Cheat Sheet - Integration Technology Matrix

Errata Page

*   Errata Page

Team

*   Core Dev Team: J.D. Meier , Alex Homer, David Hill, Jason Taylor , Prashant Bansode , Lonnie Wall, Rob Boucher Jr, Akshay Bogawat

*   Test Team - Rohit Sharma, Praveen Rangarajan, Kashinath TR, Vijaya Jankiraman

*   Edit Team - Dennis Rea.

*   External Contributors/Reviewers - Adwait Ullal; Andy Eunson; Brian Sletten; Christian Weyer; David Guimbellot; David Ing; David Weller; Derek Greer; Eduardo Jezierski; Evan Hoff; Gajapathi Kannan; Jeremy D. Miller; John Kordyback; Keith Pleas; Kent Corley; Mark Baker; Paul Ballard; Peter Oehlert; Norman Headlam; Ryan Plant; Sam Gentile; Sidney G Pinney; Ted Neward; Udi Dahan

*   Microsoft Contributors / Reviewers - Ade Miller; Amit Chopra; Anna Liu; Anoop Gupta; Bob Brumfield; Brad Abrams; Brian Cawelti; Bhushan Nene; Burley Kawasaki; Carl Perry; Chris Keyser; Chris Tavares; Clint Edmonson; Dan Reagan; David Hill; Denny Dayton; Diego Dagum; Dmitri Martynov; Dmitri Ossipov; Don Smith; Dragos Manolescu; Elisa Flasko; Eric Fleck; Erwin van der Valk; Faisal Mohamood; Francis Cheung; Gary Lewis; Glenn Block; Gregory Leake; Ian Ellison-Taylor; Ilia Fortunov; J.R. Arredondo; John deVadoss; Joseph Hofstader; Koby Avital; Loke Uei Tan; Luke Nyswonger; Manish Prabhu; Meghan Perez; Mehran Nikoo; Michael Puleio; Mike Francis; Mike Walker; Mubarak Elamin; Nick Malik; Nobuyuki Akama; Ofer Ashkenazi; Pablo Castro; Pat Helland; Phil Haack; Reed Robison; Rob Tiffany; Ryno Rijnsburger; Scott Hanselman; Seema Ramchandani; Serena Yeoh; Simon Calvert; Srinath Vasireddy; Tom Hollander; Wojtek Kozaczynski

 

To download go to following link.

http://www.codeplex.com/AppArchGuide

 

 

 

E-mail this post to someone or Comments here
Thu 16 Oct 2008

Introduction

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!!!";
vulnerable(large_buffer);

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

http://www.yourapplicationname.com/home.aspx?name=<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

Canonicalization

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
C:\myfolder\filename.zip
Filename.zip
..\filename.zip

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

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

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.

Cryptography

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.

Countermeasures

  • 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

Summary

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

http://msdn.microsoft.com/security.

 

E-mail this post to someone or Comments (1)
Wed 3 Sep 2008

Google launches internet browser

Google's new web browser is called Chrome
 It's certainly the biggest news in the browser space since Firefox started to dent Internet Explorer's lead and many people see this as a re-ignition of the browser wars 
Darren Waters

Google is launching an open source web browser to compete with Internet Explorer and Firefox.

The browser is designed to be lightweight and fast, and to cope with the next generation of web applications that rely on graphics and multimedia.

Called Chrome, it will launch as a beta for Windows machines in 100 countries, with Mac and Linux versions to come.

"We realised... we needed to completely rethink the browser," said Google's Sundar Pichai in a blog post.

The new browser will help Google take advantage of developments it is pushing online in rich web applications that are challenging traditional desktop programs.

Google has a suite of web apps, such as Documents, Picasa and Maps which offer functionality that is beginning to replace offline software.

"What we really needed was not just a browser, but also a modern platform for web pages and applications, and that's what we set out to build," Mr Pichai, VP Product Management, wrote.

Competition

The launch of a beta version of Chrome on Tuesday evening (UK time) will be Google's latest assault on Microsoft's dominance of the PC business. The firm's Internet Explorer program dominates the browser landscape, with 80% of the market.

Those already in the browser space were quick to respond to the news.

Writing in his blog, John Lilly, chief executive of Mozilla was sanguine about the new rival in the browsersphere.

"It should come as no real surprise that Google has done something here — their business is the web, and they’ve got clear opinions on how things should be, and smart people thinking about how to make things better."

Chrome will be a browser optimized for the things that they see as important, and it’ll be interesting to see how it evolves," he wrote.

He welcomed the competition and said collaboration between Mozilla and Google on certain projects would continue.

Dean Hachamovitch, general manager of Microsoft's Internet Explorer, was more bullish.

"The browser landscape is highly competitive, but people will choose Internet Explorer 8 for the way it puts the services they want right at their fingertips, respects their personal choices about how they want to browse and, more than any other browsing technology, puts them in control of their personal data online," he said in a statement.

Chrome will be available for download from the morning of Wednesday 3rd September, PST.

 

Tags: ,
E-mail this post to someone or Comments here
Fri 4 Jul 2008

Web Service Security using SOAP Extension

 

Yesterday I was trying to secure my webserice from unauthorized use.

Although there are many ways to secure webservices. Using WSE, WS-security, SOAP Extension, restricting through IP access, implementing certificates etc etc etc.

 

WSE would be the comfortable way but in my case it was time consuming to implement at both server and client end as there were hundreds of services. Restricting IP throu IIS or http handler / modules would be a good choice. I tried to do it with SOAP Extension that could be plug and play with a single entry in web.config. It works like httpmodule that reside in pipeline of communication between client and server.

 

Here after enough googling I have a very simple SOAP Extension that would help anyone if just want to secure service that request is coming from authenticated source. Although there would be still many security breaches but here you go.

 

 

What this SOAP extension will do?

Before passing request to webserver, this extension will add a string or any unique token to header of SOAP message then will pass it over network. Before server entertain the request it will look for that token or string in the header of incoming SOAP message request. If exsit then will allow to consume service else will throw an exception or whatever the action depending upon scenario.

 

 

SOAP Message Lifecycle.

 

Client = Going to accessing service

Server = Where service exists and entertaining client request.

 

 

SOAPExtension Life.gif

 

Client side

1.    A client invokes a method on the proxy class.

2.    A new instance of the SOAP extension is created on the client.

3.    If this is the first time this SOAP extension has executed with this XML Web service on the client, then the GetInitializer method is invoked on the SOAP extension running on the client.

4.    The Initialize method is invoked.

5.    The ChainStream method is invoked.

6.    The ProcessMessage method is invoked with the SoapMessageStage set to BeforeSerialize.

7.    ASP.NET on the client computer serializes the arguments of the XML Web service method into XML.

8.    The ProcessMessage method is invoked with the SoapMessageStage set to AfterSerialize.

9.    ASP.NET on the client computer sends the SOAP message over the network to the Web server hosting the XML Web service.

 

Server side

1.    ASP.NET on the Web server receives the SOAP message.

2.    A new instance of the SOAP extension is created on the Web server.

3.    On the Web server, if this is the first time this SOAP extension has executed with this XML Web service on the server side, the GetInitializer method is invoked on the SOAP extension running on the server.

4.    The Initialize method is invoked.

5.    The ChainStream method is invoked.

6.    The ProcessMessage method is invoked with the SoapMessageStage set to BeforeDeserialize.

7.    ASP.NET deserializes the arguments within the XML.

8.    The ProcessMessage method is invoked with the SoapMessageStage set to AfterDeserialize.

9.    ASP.NET creates a new instance of the class implementing the XML Web service and invokes the XML Web service method, passing in the deserialized arguments. This object resides on the same computer as the Web server.

10.  The XML Web service method executes its code, eventually setting the return value and any out parameters.

11.  The ProcessMessage method is invoked with the SoapMessageStage set to BeforeSerialize.

12.  ASP.NET on the Web server serializes the return value and out parameters into XML.

13.  The ProcessMessage method is invoked with the SoapMessageStage set to AfterSerialize.

14.  ASP.NET sends the SOAP response message over the network back to the XML Web service client.

 

Client side

1.    ASP.NET on the client computer receives the SOAP message.

2.    The ProcessMessage method is invoked with the SoapMessageStage set to BeforeDeserialize.

3.    ASP.NET deserializes the XML into the return value and any out parameters.

4.    The ProcessMessage method is invoked with the SoapMessageStage set to AfterDeserialize.

5.    ASP.NET passes the return value and any out parameters to the instance of the proxy class.

6.    The client receives the return value and any out parameters.

 

 

Here what exactly the code contains.

There are three classes.

MyHeader.cs

That will contain our security token or string that server will be looking for.

 

using System;

using System.Collections.Generic;

using System.Text;

using System.Web.Services.Protocols;

using System.Xml.Serialization;

 

    [Serializable]

    public class MyHeader : SoapHeader

    {

        private string _MyHeaderValue;

 

        public string MyHeaderValue

        {

            get { return _MyHeaderValue; }

            set { _MyHeaderValue = value; }

        }

    }

 

 

MySOAPExtensionClient.cs

SOAP Extension that will add security token in header header to outgoing SOAP message

 

using System;

using System.Web.Services;

using System.Web.Services.Protocols;

using System.IO;

using System.Net;

using System.Diagnostics;

 

    public class MySOAPExtensionClient : System.Web.Services.Protocols.SoapExtension

    {

        Stream oldStream;

        Stream newStream;

 

        public override object GetInitializer(LogicalMethodInfo methodInfo, SoapExtensionAttribute attribute)

        {

            return null;

        }

 

        public override object GetInitializer(Type WebServiceType)

        {

            return null;

        }

 

        public override void Initialize(object initializer)

        {

            return;

        }

 

        // Save the Stream representing the SOAP request or SOAP response into

        // a local memory buffer.

        public override Stream ChainStream(Stream stream)

        {

            oldStream = stream;

            newStream = new MemoryStream();

            return newStream;

        }

 

        public override void ProcessMessage(SoapMessage message)

        {

            switch (message.Stage)

            {

                case SoapMessageStage.BeforeSerialize:

                    if (message is SoapClientMessage)

                        AddHeader(message);

                    break;

                case SoapMessageStage.AfterSerialize:

                    newStream.Position = 0;

                    Copy(newStream, oldStream);

                    break;

                case SoapMessageStage.BeforeDeserialize:

                    Copy(oldStream, newStream);

                    newStream.Position = 0;

                    break;

                case SoapMessageStage.AfterDeserialize:

                    break;

            }

        }

 

        private void AddHeader(SoapMessage message)

        {

            MyHeader header = new MyHeader();

            header.MyHeaderValue = "MyValue";

            header.MustUnderstand = false;

            message.Headers.Add(header);

        }

 

        private void Copy(Stream from, Stream to)

        {

            TextReader reader = new StreamReader(from);

            TextWriter writer = new StreamWriter(to);

            writer.WriteLine(reader.ReadToEnd());

            writer.Flush();

        }

    }

 

 

 

 

MySOAPExtensionServer.cs

SOAP Extension that will will expect a security token or string in incoming SOAP request.

 

using System;

using System.Web.Services;

using System.Web.Services.Protocols;

using System.IO;

using System.Net;

using System.Diagnostics;

 

    public class MySOAPExtensionServer : System.Web.Services.Protocols.SoapExtension

    {

        Stream oldStream;

        Stream newStream;

 

        public override object GetInitializer(LogicalMethodInfo methodInfo, SoapExtensionAttribute attribute)

        {

            return null;

        }

 

        public override object GetInitializer(Type WebServiceType)

        {

            return null;

        }

 

        public override void Initialize(object initializer)

        {

            return;

        }

 

        // Save the Stream representing the SOAP request or SOAP response into

        // a local memory buffer.

        public override Stream ChainStream(Stream stream)

        {

            oldStream = stream;

            newStream = new MemoryStream();

            return newStream;

        }

 

        public override void ProcessMessage(SoapMessage message)

        {

            switch (message.Stage)

            {

                case SoapMessageStage.BeforeSerialize:

                    break;

                case SoapMessageStage.AfterSerialize:

                    newStream.Position = 0;

                    Copy(newStream, oldStream);

                    break;

                case SoapMessageStage.BeforeDeserialize:

                    Copy(oldStream, newStream);

                    newStream.Position = 0;

                    break;

                case SoapMessageStage.AfterDeserialize:

                    if (message is SoapServerMessage)

                    {

                        if (!IsRequestValid(message))

                        {

                            LoggerSecurity.GetInstance().WriteLog("Invalid Service Call | Action = " + message.Action + " | Url = " + message.Url);

                            throw new SoapException("Invalid Service Call", SoapException.ClientFaultCode);

                        }

                    }

                    break;

            }

        }

 

        private bool IsRequestValid(SoapMessage message)

        {

            bool result = false;

            try

            {

                foreach (SoapHeader header in message.Headers)

                {

                    if (header is MyHeader)

                    {

                        MyHeader head = (MyHeader)header;

                        if (head.MyHeaderValue.Equals("MyValue"))

                            result = true;

                    }

                       

                       

                    else if (header is SoapUnknownHeader)

                    {

                        System.Xml.XmlElement elem = ((SoapUnknownHeader)header).Element;

                        if (elem.Name.Equals("MyHeader"))

                        {

                            System.Xml.XmlNode node = elem.SelectSingleNode("/");

                            if (node != null && node.InnerText.Equals("MyValue"))

                                result = true;

                        }

                    }

                }

            }

            catch (Exception ex)

            {

                LoggerSecurity.GetInstance().WriteLog(ex);

            }

            return result;

        }

 

        private void Copy(Stream from, Stream to)

        {

            TextReader reader = new StreamReader(from);

            TextWriter writer = new StreamWriter(to);

            writer.WriteLine(reader.ReadToEnd());

            writer.Flush();

        }

    }

 

 

In Client Web.Config before ending system.Web section add following

 

        <webServices>

              <protocols>

                    <remove name="HttpGet" />

                    <remove name="HttpPost" />

                    <remove name="HttpPostLocalhost" />

                    <remove name="Documentation" />

              </protocols>

              <soapExtensionTypes>

                    <add type="CustSoapExtension.MySOAPExtensionClient, CustSoapExtension" priority="1" group="High"/>

              </soapExtensionTypes>

        </webServices>

 

  </system.web>

 

 

 

In Server Web.Config before ending system.Web section add following

 

        <webServices>

              <protocols>

                    <remove name="HttpGet" />

                    <remove name="HttpPost" />

                    <remove name="HttpPostLocalhost" />

                    <remove name="Documentation" />

              </protocols>

              <soapExtensionTypes>

                    <add type="CustSoapExtension.MySOAPExtensionClient, CustSoapExtension" priority="1" group="High"/>

              </soapExtensionTypes>

        </webServices>

 

  </system.web>

 

 

Why these?

                    <remove name="HttpGet" />

                    <remove name="HttpPost" />

                    <remove name="HttpPostLocalhost" />

                    <remove name="Documentation" />

 

On production environment, if there is required only to consume webservices using only SOAP then don’t allow aceess to service using these protocoals. Only allow SOAP protocol.

 

 

Hope this sample code will help you to improve your security concern.

 

E-mail this post to someone or Comments (3)
Tue 24 Jun 2008


Configuration File Tampering

If Configuration files are not protected then you should use the file system access control list (ACL) to protect them.


System Registry Tampering

If registry entries are not protected then you should use the registry ACL to protect them.


Repudiation / Logging

Security exceptions should be logged for auditing purposes; therefore, you should define and implement logging and auditing strategies in the code. Push security exceptions–related information to the event log.


Assembly Tampering

To prevent assembly tampering, consider implementing Authenticode signatures for these assemblies.


Authentication and Authorization

You should consider various Internet, intranet, and extranet-based deployment for Web servers and database servers, and then implement appropriate authentication mechanisms.


Message Protection

You should implement transport-level security (secure socket layer [SSL]) to further strengthen the communication channel. You can also implement IPsec to secure communication channel between services and the database. To implement message-level security, use either WSE 3.0 or WCF to sign and encrypt messages. Choose appropriate certificates and encryption algorithms to enforce security without compromising business operations and performance.


HTTP Replay
Attacks

You can prevent these attacks by providing a secure end-to-end communication channel between server and client (for example, SSL). You should also uniquely authenticate each request (for example, use a timestamp and digital signature), by implementing message-level security. Implement IP lockout policies if required.


Denial of Service

You can prevent denial of service attacks by implementing strong authentication, authorization, and request validation mechanisms. Also, you should uniquely authenticate each request (for example, use a timestamp and digital signature) by implementing message-level security.


Repudiation

You can prevent repudiation attacks by implementing strong authentication, authorization, and request validation mechanisms. Also, you should implement the history and auditing feature for any database operations. You should not permanently delete the records from the database.


Dictionary Attack or Password Brute Force
Attack

You should try to prevent dictionary attacks or password brute force attacks. Implement strong password policies to prevent password hijacking. Implement a maximum retries policy, and disable the account if the number of attempts exceeds the maximum number. Also, implement an IP lockout policy, if required. Implement auditing and logging for service contracts / Web server / service host access.


Spoofing

You can prevent spoofing attacks by implementing strong authentication, authorization, and request validation mechanisms.


Database Security Access Controls

Use an account that has restricted permissions in the database. Ideally, you should grant execute permissions only to selected stored procedures. Consider using database role and application role database security concepts to access a different set of database objects. For example, consider using different sets of database roles and application roles for read-only operations and read-write operations.


Configuration Files Clear Text Secrets

To protect your connection strings, secret app settings, consider using DPAPI to encrypt them and store clear text secrets in a restricted registry. Use file ACLs to control access to configuration files.


Database Clear Text Secrets

The database contains secrets in clear text. For a production application, you should consider encrypting sensitive data.


Web Service Documentation Protocol

The Web.config file allows a malicious user to see the Web service documentation (wsdl file) by using documentation protocol. Using this information, the malicious user can get information about all data contracts and service contract details. The malicious user can then use the details to launch brute force attacks or false request attacks. You should configure the Web.config file to disable the documentation protocol.


Debug Attribute

The host program configuration file allows debugging. The Web.config file describes the debug = true attribute, which can allow the malicious user to debug the service implementation. This opens extra surface area, which allows a malicious user to explore injection threats. To prevent this type of attack, configure debug = false in the Web.config file.


CustomErrors Mode Attribute

The host program configuration file allows debugging. The Web.config file describes the CustomErrors Mode = off attribute, which can allow the malicious user to see the complete debug information in case of errors or exceptions. A malicious user can get the call stack information, which can launch injection or code malfunction attacks. To prevent this type of attack, configure CustomErrors Mode = on and make sure that the defaultUrl is appropriately configured in the Web.config file.

 

PersistSecurityInfo Attribute

The database connection string in the Web.config file does not contain a definition for the PersistSecurityInfo attribute. This attribute should be set to false. When set to false, sensitive information, such as the password, is not returned as part of the connection if the connection is open or has ever been in an open state. Resetting the connection string resets all connection string values, including the password. Set the PersistSecurityInfo attribute to false in the connection string.


SqlClientPermission Attribute

The database access assembly does not define the code access security attribute SqlClientPermission.

The CustomerRepository assembly should request minimum security permissions for SqlClientPermission.


Unrestricted Base Classes

When developing classes that will be deployed to a production environment, you should consider using sealed attributes for classes and methods.

 

E-mail this post to someone or Comments (1)