.NET Naming Capitalization Styles

Use the following three conventions for capitalizing identifiers.

Pascal case

The first letter in the identifier and the first letter of each subsequent concatenated word are capitalized. You can use Pascal case for identifiers of three or more characters. For example: BackColor, CodeLibrary

Camel case

The first letter of an identifier is lowercase and the first letter of each subsequent concatenated word is capitalized. For example: backColor, isActive,

Uppercase

All letters in the identifier are capitalized. Use this convention only for identifiers that consist of two or fewer letters. For example: system.IO,

You might also have to capitalize identifiers to maintain compatibility with existing, unmanaged symbol schemes, where all uppercase characters are often used for enumerations and constant values. In general, these symbols should not be visible outside of the assembly that uses them.

The following table summarizes the capitalization rules and provides examples for the different types of identifiers.

Identifier	Case	Example
Class	Pascal	AppDomain
Enum type	Pascal	ErrorLevel
Enum values	Pascal	FatalError
Event	Pascal	ValueChange
Exception class	Pascal	WebException Note Always ends with the suffix Exception.
Read-only Static field	Pascal	RedValue
Interface	Pascal	IDisposable Note Always begins with the prefix I.
Method	Pascal	ToString
Namespace	Pascal	System.Drawing
Parameter	Camel	typeName
Property	Pascal	BackColor
Protected instance field	Camel	redValue Note Rarely used. A property is preferable to using a protected instance field.
Public instance field	Pascal	RedValue Note Rarely used. A property is preferable to using a public instance field.

Authentication Hacking Attacks

Authentication plays a critical role in the security of web applications. When a user provides his login name and password to authenticate and prove his identity, the application assigns the user specific privileges to the system, based on the identity established by the supplied credentials.

HTTP can embed several different types of authentication protocols. These include:

Basic - Cleartext username/password, Base-64 encode (trivially decoded)
Digest - Like Basic, but passwords are scrambled
Form-based - A custom form is used to input username/password (or other credentials) and is processed using custom logic on the backend.
NTLM - Microsoft's proprietary authentication protocol, implemented within HTTP request/response headers.
Negotiate - A new protocol from Microsoft that allows any type of authentication specified above to be dynamically agreed upon by the client and server. Also adds Kerberos for clients using Microsoft's IE v5+.
Client-side Certificates - Although rarely used, SSL/TLS provides an option that checks the authenticity of a digital certificate present by the Web client, essentially making it an authentication token.
Microsoft Passport - A single-sign-in (SSI) service run by Microsoft Corporation that allows web sites (called "Passport Partners") to authenticate users based on their membership in the Passport service. The mechanism uses a key shared between Microsoft and the Partner site to create a cookie that uniquely identifies the user.
These authentication protocols operate right over HTTP (or SSL/TSL), with credentials embedded right in the request/response traffic.

This kind of attack is not a technological security hole in the Operating System or server software. It depends rather on how securely stored and complex the passwords are and on how easy it is for the attacker to reach the server (network security).

When the attacker breaks into the system by proving to the application that he is a known and valid user, the attacker gains access to whatever privileges the administrator assigned that user.
This means that if the attacker manages to enter as a normal user, he might have limited access to only view some important information. On the other hand, if he manages to enter as an administrative user with global access on the system, he would have almost total control on the application together with its content (with the limitations of the web application in itself).

Generally an attacker first tries to gain access to the prompt/login screen where the application would request a login and password. The next step would be to enter a correct match of login and password that the application would recognise as correct and which has high privileges in the system.

Although not the best of attacks, password guessing can be one of the most effective techniques to defeat web authentication. This technique can be carried out either manually or via automated procedures. If password guessing achieves no result, the next step for an attacker is to try other password combinations using special custom tools, like WebCracker and Brutus, which are readily available on the internet.


To verify whether an attack phase has succeeded or not, automated tools assess the returned error codes and page information from the host web server. A secure practice is to force any error or unexpected request to generate a HTTP 200 OK response, instead of the numerous 400 type errors. This will make it more difficult for the attacker to distinguish between valid and invalid login attempts.

An important measure in stopping automated brute-force authentication attacks is by adding random content on the page presented to the authenticating client browser. The client must be capable of successfully submitting this random content as part of the authentication process to proceed further in the web site or application. The best way to do this is to present the random phrase in a graphic GIF, JPG or PNG format using random fonts or colours each time. This can make it almost impossible for an automated process to succeed.

CROSS SITE SCRIPTING (CSS Attack)

Cross Site Scripting (also known as XSS or CSS) generally occurs when a dynamic web page gathers malicious data from a user and displays the input on the page without it being properly validated. The data is usually formatted in the form of a hyperlink which contains malicious content within it and is distributed over any possible means on the internet.

This generally happens when Developers pass strings through QueryString and those are directly used in SQL-Queries or printed on Page. Attackers can pass complete scripts by manipulating these strings and gain control of your site.

Please note that ASP.NET prevents XSS attack to a greater extent. In order to prevent this attack in ASP or PHP, please do not use the Query String directly in Code. Before printing or executing any variable in Query String, please check it for malicious data.

For Example,
you have a variable "msg" passed through querystring through which you pass a message that is to be printed on screen (like "Invalid User"). Your URL will somehow look like this...
http://localhost/mysite/
default.asp?msg=Invalid%20User

And if on your page you are printing this variable as it is, than any hacker, even a beginner can misuse this vulnerability.

One can write
http://localhost/mysite/
default.asp?msg=<script>alert("hi");</script>

This will inject a script in your page and when the page is loader, and alert will be displayed. This example uses a simple alert. Real hacker/cracker would use something more disastrous.

CRLF Injection Attack

The term CRLF stands for Carriage Return (CR, ASCII 13, \r) Line Feed (LF, ASCII 10, \n). These are ACSII characters which display nothing on screen but are very widely used in Windows to indicate an end of line. On Linux/UNIX systems the end of line is indicated by the use of the Line Feed only. This combination of CR and LR is used for example when pressing "Enter" on the keyboard. Depending on the application being used, pressing "Enter" generally instructs the application to start a new line, or to send a command. A CRLF Injection attack occurs when a hacker manages to inject CRLF Commands into the system. For example, if you are using a simple text file to store some data accepted from user, and user enters a line that contains \n or other formfeed/linefeed character, the application will treat it as two seperate entries. This security Hole must be prevented by all developers. Preventing such flaw is very easy, provided the developer is little alert while developing the application. Show parent | Reply

GOOGLE INJECTION

Google hacking is the term used when a hacker tries to find exploitable targets and sensitive data by using search engines. The Google Hacking Database (GHDB) is a database of queries that identify sensitive data. Although Google blocks some of the better known Google hacking queries, nothing stops a hacker from crawling your site and launching the Google Hacking Database queries directly onto the crawled content.

The Google Hacking Database is located at http://johnny.ihackstuff.com . More information about Google hacking can be found on: http://www.informit.com/articles/article.asp?p=170880&rl=1

What a hacker can do if your site is vulnerable
Information that the Google Hacking Database identifies:

Advisories and server vulnerabilities
Error messages that contain too much information
Files containing passwords
Sensitive directories
Pages containing logon portals
Pages containing network or vulnerability data such as firewall logs.

There is only one solution to this. Study the logic of Google Hacking, and remove all pages that contain information vulnearable to GoogleHacking.

Search by SOUNDEX and DIFFERENCE

In late nineteenth century, the United States Census decided to create a method by which they can search people even if they don't know the exact spelling of name. This method was called Soundex Phonetic Filling System. This system used simple phonetic algorithm that was capable of reducung any word to a four character alphanumeric code in which the First character of name is not changed and rest of the characters are converted to a numeral.

Now this technique has been introduced in almost every DBMS. We shall discuss two functions from MS-SQL that help us recognise Vikramjit and Vikramjeet as same. But remember that different database systems have implemented different algorithms, which means that phonetic code of MS-SQL may not match to code of ORACLE or MySQL.

SOUNDEX FUNCTION
This function is having a very simple syntax. Just write...
SELECT * FROM <table_name> WHERE SOUNDEX(<var1>) = SOUNDEX(<var2>)
As a result, it will Compare Var1 and Var2. If Var1 has value Vikramjit and Var2 has value VIKRAMJEET, they will be treated equally. Similarily, Ajay=Ajoy, Dave=Daev and Chopsey=Chopsi

DIFFERENCE FUNCTION
If you want to work with Threshold and want to perform mathematical magic on names, this is the function on you.
SELECT * FROM <table_name>WHERE DIFFERENCE(<var1>,<var2>) <= 2
The difference function returns a value between 1 and 4 where 1 is least similar and 4 is most similar.

Happy Querying...

Good Coding Practices: Basic Data Handling

7.1 General Database Access

Database Access should be done through a predefined class and Developer must create this class in his project or include the pre-defined component for same if available.

The class is expected to hold fully documented functions that are capable of handling data access through queries, stored procedures and UDFs.

All developers must make sure at there part that connection should be opened only when required and should be closed and objects disposed when the context ends.


7.2 Data Fetching and Display
While displaying data, following things must be taken care of…

NULL should be explicitly handled while displaying field.
The condition that no rows are present should be explicitly handled and a proper message must appear stating that no data is present.
Query should be optimized in such a way that only relevant fields are fetched and only relevant rows are retrieved from database.
Developer should try to create the query in Query Analyzer as it helps in creating more efficient queries.


7.3 Data Insertion and Updating
While inserting or updating data in database, following things must be taken care of…

1. Data of correct data-type is sent for insertion or updation to avoid any error
2. Single quote or other terminating character must be explicitly replaced.
e.g.: variable = replace(variable,”’”,”’’”) (replacing single quote with two single quoted for MS-SQL)
3. The insert query must specify all field names explicitly (e.g. insert into tablename(fieldname1,fieldname2) values(1,’2’) )

7.4 Schema and Database Structure
While creating database, following points should be kept in mind…

Naming Conventions should be strictly followed.
The Database should be partially normalized using the star normalization structure
Proper constraints like Primary Key and Default value should be specified
Data Size should be in such a manner that space is not wasted and objective is also fulfilled

7.5 Data Transfer
While transferring data from one place to another, please observe the following procedure. It should be noted that the following procedure is must as it helps in bypassing several possibilities of errors and is very fast also

Create a Script of Database with all Triggers, Stored Procedures, Functions, Views, Users and Roles etc.
Execute the script at destination. (If database is to be created with a different name, manual changes can be done to replace the old name with new name in script)
Use normal Data Transformation Service or any available Import/Export utility to transfer data from source to destination (without structure)