Something About

Saraswati Puja: The Festival Of Goddess Saraswati

2011-02-08T02:00:00.000-08:00

C sharp : To print dynamic pyramid.

2011-01-28T05:28:00.000-08:00

Now , You can play with pyramids and many different shapes from below mentioned programmed :-

Program(1): To print 1 * 10 Counting Table.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace pyramid
{
   class Program
   {
   static void Main(string[] args)
   {
   int k, l;
   for (k = 1; k < 11; k++)
   {
   for (l = 1; l < 11; l++)
   {
   Console.Write(" | ");
   Console.Write(k * l);
   }
   Console.WriteLine("\n");
   }
   }
   }
}

Program(2): To print pyramid as you like.

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

namespace pyramid

{

class Program

{

static void Main(string[] args)

{

   {
   Console.WriteLine("Enter the value ");
   int k = int.Parse(Console.ReadLine());
   int n = k - 1;
   int x = 2 * (k - 1) + 1;
   for (int p = 0; p <= n; p++)
   {
   for (int j = k - 1; j >= 0; j--)
   {
   Console.Write(" ");
   }
   for (int i = 0; i <= (x - 2 * (k - 1)); i++)
   {
   if (i % 2 == 1)
   {
   Console.Write("*");
   }
   else
   {
   Console.Write(" ");
   }
   }
   Console.WriteLine();
   k--;
   }
   Console.ReadLine();
   }
     }
   }
}

Program(3): To print Tower of Hanoui....

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

namespace pyramid

{

class Program

{

static void Main(string[] args)

{

   try
   {
   Console.Write("Enter the for Tower of Hanaui: ");
   int n = Convert.ToInt32(Console.ReadLine());
   for (int i = 1; i <= n; i++)
   {
   for (int j = n; j >= i; j--)
   {
   Console.Write(" ");
   }
   for (int k = 1; k <= i; k++)
   {
   Console.Write("*");
   }
   for (int m = 2; m <= i; m++)
   {
   Console.Write("*");
   }
   Console.WriteLine();
   for (int a = 1; a <= n; a++)
   {
   for (int j = n; j >= i; j--)
   {
   Console.Write(" ");
   }
   for (int k = 1; k <= i; k++)
   {
   Console.Write("*");
   }
   for (int m = 2; m <= i; m++)
   {
   Console.Write("*");
   }
   Console.WriteLine();
   }
   }
   }
   catch (Exception ex)
   {
   Console.WriteLine(ex.Message);
   }

}

}

Start Program(4): To print Zigzag Tower

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

namespace pyramid

{

class Program

{

static void Main(string[] args)

{

   try
   {
   Console.Write("Enter number for Zigzag Tower: ");
   int n = Convert.ToInt32(Console.ReadLine());
   for (int i = 1; i <= n; i++)
   {
   for (int j = n; j >= i; j--)
   {
   Console.Write(" ");
   }
   for (int k = 1; k <= i; k++)
   {
   Console.Write("*");
   }
   for (int m = 2; m <= i; m++)
   {
   Console.Write("*");
   }
   Console.WriteLine();
   for (int a = 1; a <= n; a++)
   {
   for (int b = n; b >= a; b--)
   {
   Console.Write(" ");
   }
   for (int k = 1; k <= i; k++)
   {
   Console.Write("*");
   }
   for (int m = 2; m <= i; m++)
   {
   Console.Write("*");
   }
   Console.WriteLine();
   }
   }
   }
   catch (Exception ex)
   {
   Console.WriteLine(ex.Message);
   }
   }
   }
}

Program(5): To print Nexted Pyramid...

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

namespace pyramid

{

class Program

{

static void Main(string[] args)

{

   try
   {
   Console.Write("Enter number for nexted pyramid: ");
   int n = Convert.ToInt32(Console.ReadLine());
   for (int i = 1; i <= n; i++)
   {
   for (int j = n; j >= i; j--)
   {
   Console.Write(" ");
   }
   for (int k = 1; k <= i; k++)
   {
   Console.Write("*");
   }
   for (int m = 2; m <= i; m++)
   {
   Console.Write("*");
   }
   Console.WriteLine();
   for (int a = 1; a <= n; a++)
   {
   for (int b = n; b >= a; b--)
   {
   Console.Write(" ");
   }
   for (int c = 1; c <= a; c++)
   {
   Console.Write("*");
   }
   for (int d = 2; d <= a; d++)
   {
   Console.Write("*");
   }
   Console.WriteLine();
   }
   }
   }
   catch (Exception ex)
   {
   Console.WriteLine(ex.Message);
   }
   }
   }
}

Program(6): To print two simultaneouly Pyramid...

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

namespace pyramid

{

class Program

{

static void Main(string[] args)

{

   try
   {
   Console.Write("Enter number for simultaneously pyramid: ");
   int n = Convert.ToInt32(Console.ReadLine());
   for (int i = 1; i <= n; i++)
   {
   for (int j = n; j >= i; j--)
   {
   Console.Write(" ");
   }
   for (int k = 1; k <= i; k++)
   {
   Console.Write("*");
   }
   for (int m = 2; m <= i; m++)
   {
   Console.Write("*");
   }
   Console.WriteLine();
   }
   {
   for (int a = 1; a <= n; a++)
   {
   for (int b = n; b >= a; b--)
   {
   Console.Write(" ");
   }
   for (int c = 1; c <= a; c++)
   {
   Console.Write("*");
   }
   for (int d = 2; d <= a; d++)
   {
   Console.Write("*");
   }
   Console.WriteLine();
   }
   }
   }
   catch (Exception ex)
   {
   Console.WriteLine(ex.Message);
   }
   }
   }
}

  I hope you enjoy and learn lots of programming concepts; basically looping concepts. You can contact us through this blog or email me at: ksantosh.mca@gmail.com
Thanks, Happy programming..

S. K. Singh

Mobile Number Portability

2011-01-21T21:40:00.000-08:00

The Telecom Regulatory Authority of India (TRAI) announced, on November 20, 2009, that Mobile Number Portability (MNP) will be introduced in India, on December 31, 2009.

TRAI said that subscribers in India will be able to change their service providers while keeping the same mobile number, at a fee of no more than Rs 19. It doesn’t matter whether you want switch from GSM to CDMA or vice-versa, or within GSM and CDMA opetaors; you can still retain the same number. However, initially, you will be able to switch operators and retain the number only within the same telecom circle. You cannot retain the same number and change operators if you want to, say, move from Delhi to Mumbai.

Mobile Number Portability changeover charges

TRAI also said that service providers will be able to charge any amount less than or equal to Rs 19.

MNP will be introduced in India, in two phases. It will first be introduced in Indian metros and Category A telecom zones, on December 31, 2009, and subsequently in the rest of the country, by March 20, 2010.

How to change mobile operator under MNP

Subscribers must pay up all pending bills before making an application for MNP. The porting fees is to be paid to the new operator. No payment is required to be given to the operator you are leaving. TRAI said that porting between mobile operators should be accomplished within four days. There’s a catch though. You cannot switch operator and retain number if you have been with that operator for less than three months. Prepaid users must remember that their balance talk time will disappear if they switch to a different operator. The maximum downtime between deactivating the existing connection and starting the new connection will be a maximum of two hours.

As for Dipping charges, the charge will be mutually agreed upon between a service provider or international long distance provider to the MNP service provider.

Frequently Asked Questions

What is mobile number portability?
   Mobile number portability allows subscriber to opt for service provider of his choice but retain his mobile number. The number gets ported to the new provider.
Does it allow a technology switch?
  Subscriber can stay with same technology, GSM/CDMA. Also change to CDMA or vice versa. Both post-paid & prepaid subscribers can use it.
How long will it take to port a number?
  Seven working days. Fifteen days in J&K, North-east .
How expensive?
Will cost Rs19, to be collected by new service provider.

Can you retain your number in another city?
No. You can't change circles.

How frequently can you switch service providers?
A subscriber must be with a provider for at least three months.

To switch, send the following text PORT mobile number to 1900.

You'll get an eight-digit alphanumeric code and expiry date for it. This is the unique porting code.

Approach service provider you have opted for with unique code. Carry address & ID proof/ photograph/ application form with unique code & mobile number. Complete this process within the expiry date that came with unique code.

Operator will take request to mobile portability clearing house. Clearing house will get your number deactivated from existing provider and activate new one.

You'll then get text from new provider mentioning date & time when phone will go through a no-service period.

हम नागरिक इस देश के !

2011-01-20T20:29:00.000-08:00

पहले कर्तव्य, फिर अधिकार
पूरी दुनिया एक हो चुकी है। आज हम जी रहे है ग्लोबल व‌र्ल्ड में। ऐसे में हमें अपनी सोच को भी विस्तार देना चाहिए। हमें अपने कर्तव्यों को नजर अंदाज नहीं करना चाहिए। आप जिस भी क्षेत्र में है, आपको जो भी जिम्मेदारी मिली है, उसे निभा लीजिए। बस इतना करना ही काफी है एक बेहतर नागरिक बनने के लिए।
जिम्मेदारी का अहसास
हमारे देश की समृद्ध सभ्यता-संस्कृति की चर्चा दुनिया भर में होती है, लेकिन जब बात सिविक सेंस की आती है, तो हमारी गिनती पीछे क्यों होती है? इस बारे में सोचने का यह सही वक्त है। मेरे खयाल से इसका एक कारण यह है कि अपने अधिकारों के प्रति सजग होने की बात तो हम करते है, लेकिन कर्तव्यों के प्रति उतने सचेत नहीं रहते। इसलिए रूल्स तोड़ने में हमें ज्यादा मलाल नहीं होता। सार्वजनिक संपत्तिका नुकसान होने से हमें तकलीफ नही होती। देश के नागरिक होने के नाते हमें अपने कर्तव्यों हमेशा याद रखने चाहिए। और क्या बस यही एक उपाय है सिविक सेंस को डेवलप करने का। मुझे भरोसा है वह दिन दूर नहीं जब होंगे दुनिया के बेस्ट नागरिक।
करनी होगी पहल
जब सड़क पर कोई कूड़ा फेंकता है, लाइन तोड़ आगे बढ़कर अपना काम करवा लेता है, तो ऐसी हरकतें खीझ पैदा कर देती हैं। लेकिन क्या केवल ऐसे लोगों से चिढ़कर रह जाने से पैदा हो जाएगा सिविक सेंस? जब मुझे यह बात समझ में आई, तो उस दिन से मुझे सिविक सेंस का महत्व और इसे विकसित करने का सबसे बेहतर तरीका भी पता चला। वह है खुद को सुधार लें, अपनी छोटी-छोटी गलत आदतें छोड़ दें, तो जरूर कुछ बदलाव होगा। मेरी समझ से सिविक सेंस डेवलप करने का एक ही उपाय है कि बातें करने की बजाय पहल करके काम शुरू करें।
खुद पर हो भरोसा

दुनिया में हमें काफी सम्मान की नजरों से देखा जाता है, क्योंकि?हर मोर्चे पर हमारी एक अलग पहचान है।?जिधर देखो उधर भारत का नाम है। लेकिन अफसोस जब सिविक सेंस की बात की जाती है, तो भारतीयों को इस मामले में पिछड़ा हुआ समझ लिया जाता है।

मजे की बात यह है कि हममें से ज्यादातर आज भी खुद को भी विदेशियों से पीछे मानते है। इसका तो अर्थ यही है न कि हमारे अंदर आत्मविश्वास की कमी है। हमें यह नहीं सोचना चाहिए कि हम पिछड़े हुए और अभद्र है। यदि हम खुद ही ऐसा सोचने लगेंगे, तो फिर कैसे बन पाएंगे बेहतर नागरिक? आखिर हर काम के लिए खुद पर भरोसा होना तो जरूरी है न।

What is the difference between 1G,2G,3G & 4G ?

2011-01-18T20:53:00.000-08:00

In 1G, Narrow band analogue wireless network is used, with this we can have the voice calls and can send text messages. These services are provided with circuit switching.Then in case of 2G Narrow Band Wireless Digital Network is used. It brings more clarity to the conversation .Both the 1G and 2G deals with voice calls and has to utilize the maximum bandwidth.In 3G Wide Brand Wireless Network is used with which the clarity increases and gives the perfection as like that of a real conversation. The data are sent through the technology called Packet Switching .Voice calls are interpreted through Circuit Switching.Then with the case of Fourth Generation that is 4G in addition to that of the services of 3G some additional features such as Multi-Media Newspapers, also to watch T.V programs with the clarity as to that of an ordinary T.V. In addition, we can send Data much faster that that of the previous generations.

For more details you can visit below links :-
http://www.daniweb.com/forums/thread35959.html
http://hubpages.com/hub/3G-and-4G-Mobile-Services
http://indianblogger.com/understanding-the-generations-1g-2g-3g-and-4g
http://www.channelpartnersonline.com/articles/2007/01/2g-3g-4g-gigi.aspx

Top 10 Application Security Vulnerabilities in Web.config Files

2011-01-12T23:22:00.000-08:00

These days, the biggest threat to an organization’s network security comes from its public

Web site and the Web-based applications found there. Unlike internal-only network

services such as databases—which can be sealed off from the outside via firewalls—a

public Web site is generally accessible to anyone who wants to view it, making

application security an issue. As networks have become more secure, vulnerabilities in

Web applications have inevitably attracted the attention of hackers, both criminal and

recreational, who have devised techniques to exploit these holes. In fact, attacks upon the

Web application layer now exceed those conducted at the network level, and can have

consequences which are just as damaging.

Some enlightened software architects and developers are becoming educated on these

threats to application security and are designing their Web-based applications with

security in mind. By "baking in" application security from the start of the development

process, rather than trying to ”brush it on” at the end, you are much more likely to create

secure applications that will withstand hackers' attacks. However, even the most

meticulous and security-aware C# or VB.NET code can still be vulnerable to attack if

you neglect to secure the Web.config configuration files of your application. Incorrectly

configured Web-based applications can be just as dangerous as those that have been

incorrectly coded. To make matters worse, many configuration settings actually default to

insecure values.

This article lists five of the “worst offenders” of misconfigurations of application security

that are universally problematic for all ASP.NET Web-based applications. Part two of

this article will list an additional five misconfigurations that are specifically applicable to

ASP.NET sites that use Web Forms authentication. So without further ado, let’s get

started!

1. Custom Errors Disabled

When you disable custom errors as shown below, ASP.NET provides a detailed error

message to clients by default.

Vulnerable configuration:

<system.web>

Secure configuration:

<system.web>

In itself, knowing the source of an error may not seem like a risk to application security,

but consider this: the more information a hacker can gather about a Web site, the more

likely it is that he will be able to successfully attack it. An error message can be a gold

mine of information to an attacker. A default ASP.NET error message lists the specific

versions of ASP.NET and the .NET framework which are being used by the Web server,

as well as the type of exception that was thrown. Just knowing which Web-based

applications are used (in this case ASP.NET) compromises application security by telling

the attacker that the server is running a relatively recent version of Microsoft Windows

and that Microsoft Internet Information Server (IIS) 6.0 or later is being used as the Web

server. The type of exception thrown may also help the attacker to profile Web-based

applications; for example, if a SqlException is thrown, then the attacker knows that

the application is using some version of Microsoft SQL Server.

You can build up application security to prevent such information leakage by modifying

the mode attribute of the <customErrors> element to On or RemoteOnly. This setting

instructs Web-based applications to display a nondescript, generic error message when an

unhandled exception is generated. Another way to circumvent this application security

issue is to redirect the user to a new page when errors occur by setting the

defaultRedirect attribute of the <customErrors> element. This approach can

provide even better application security because the default generic error page still gives

away too much information about the system (namely, that it's using a Web.config file,

which reveals that the server is running ASP.NET).

2. Leaving Tracing Enabled in Web-Based Applications

The trace feature of ASP.NET is one of the most useful tools that you can use to ensure

application security by debugging and profiling your Web-based applications.

Unfortunately, it is also one of the most useful tools that a hacker can use to attack your

Web-based applications if it is left enabled in a production environment.

Vulnerable configuration:

<system.web>

Secure configuration:

<system.web>

When the <trace> element is enabled for remote users of Web-based applications

(localOnly="false"), any user can view an incredibly detailed list of recent requests

to the application simply by browsing to the page trace.axd. If a detailed exception

message is like a gold mine to a hacker looking to circumvent application security, a trace

log is like Fort Knox! A trace log presents a wealth of information: the .NET and

ASP.NET versions that the server is running; a complete trace of all the page methods

that the request caused, including their times of execution; the session state and

application state keys; the request and response cookies; the complete set of request

headers, form variables, and QueryString variables; and finally the complete set of server

variables.

A hacker looking for a way around application security would obviously find the form

variable histories useful because these might include email addresses that could be

harvested and sold to spammers, IDs and passwords that could be used to impersonate the

user, or credit card and bank account numbers. Even the most innocent-looking piece of

data in the trace collection can be dangerous in the wrong hands. For example, the

APPL_PHYSICAL_PATH server variable, which contains the physical path of Web-based

applications on the server, could help an attacker perform directory traversal attacks

against the system.

The best way to prevent a hacker from obtaining trace data from Web-based applications

is to disable the trace viewer completely by setting the enabled attribute of the

<trace> element to false. If you have to have the trace viewer enabled, either to

debug or to profile your application, then be sure to set the localOnly attribute of the

<trace> element to true. That allows users to access the trace viewer only from the

Web server and disables viewing it from any remote machine, increasing your application

security.

3. Debugging Enabled

Deploying Web-based applications in debug mode is a very common mistake. Virtually

all Web-based applications require some debugging. Visual Studio 2005 will even

automatically modify the Web.config file to allow debugging when you start to debug

your application. And, since deploying ASP.NET applications is as simple as copying the

files from the development folder into the deployment folder, it’s easy to see how

development configuration settings can accidentally make it into production,

compromising application security.

Vulnerable configuration:

<system.web>

Secure configuration:

<system.web>

Like the first two application security vulnerabilities described in this list, leaving

debugging enabled is dangerous because you are providing inside information to end

users who shouldn’t have access to it, and who may use it to attack your Web-based

applications. For example, if you have enabled debugging and disabled custom errors in

your application, then any error message displayed to an end user of your Web-based

applications will include not only the server information, a detailed exception message,

and a stack trace, but also the actual source code of the page where the error occurred.

Unfortunately, this configuration setting isn't the only way that source code might be

displayed to the user. Here's a story that illustrates why developers shouldn’t concentrate

solely on one type of configuration setting to improve application security. In early

versions of Microsoft’s ASP.NET AJAX framework, some controls would return a stack

trace with source code to the client browser whenever exceptions occurred. This behavior

happened whenever debugging was enabled, regardless of the custom error setting in the

configuration. So, even if you properly configured your Web-based applications to

display non-descriptive messages when errors occurred, you could still have

unexpectedly revealed your source code to your end users if you forgot to disable

debugging.

To disable debugging, set the value of the debug attribute of the <compilation>

element to false. This is the default value of the setting, but as we will see in part two

of this article, it’s safer to explicitly set the desired value rather than relying on the

defaults to protect application security.

4. Cookies Accessible through Client-Side Script

In Internet Explorer 6.0, Microsoft introduced a new cookie property called HttpOnly.

While you can set the property programmatically on a per-cookie basis, you also can set

it globally in the site configuration.

Vulnerable configuration:

<system.web>

Secure configuration:

<system.web>

Any cookie marked with this property will be accessible only from server-side code, and

not to any client-side scripting code like JavaScript or VBScript. This shielding of

cookies from the client helps to protect Web-based applications from Cross-Site Scripting

attacks. A hacker initiates a Cross-Site Scripting (also called CSS or XSS) attack by

attempting to insert his own script code into the Web page to get around any application

security in place. Any page that accepts input from a user and echoes that input back is

potentially vulnerable. For example, a login page that prompts for a user name and

password and then displays “Welcome back, <username>” on a successful login may be

susceptible to an XSS attack.

Message boards, forums, and wikis are also often vulnerable to application security

issues. In these sites, legitimate users post their thoughts or opinions, which are then

visible to all other visitors to the site. But an attacker, rather than posting about the

current topic, will instead post a message such as

“<script>alert(document.cookie);</script>”. The message board now

includes the attacker’s script code in its page code—and the browser then interprets and

executes it for future site visitors. Usually attackers use such script code to try to obtain

the user’s authentication token (usually stored in a cookie), which they could then use to

impersonate the user. When cookies are marked with the HttpOnly property, their

values are hidden from the client, so this attack will fail.

As mentioned earlier, it is possible to enable HttpOnly programmatically on any

individual cookie by setting the HttpOnly property of the HttpCookie object to true.

However, it is easier and more reliable to configure the application to automatically

enable HttpOnly for all cookies. To do this, set the httpOnlyCookies attribute of the

<httpCookies> element to true.

5. Cookieless Session State Enabled

In the initial 1.0 release of ASP.NET, you had no choice about how to transmit the

session token between requests when your Web application needed to maintain session

state: it was always stored in a cookie. Unfortunately, this meant that users who would

not accept cookies could not use your application. So, in ASP.NET 1.1, Microsoft added

support for cookieless session tokens via use of the “cookieless” setting.

Vulnerable configuration:

<system.web>

Secure configuration:

<system.web>

Web applications configured to use cookieless session state now stored the session token

in the page URLs rather than a cookie. For example, the page URL might change from

http://myserver/MyApplication/default.aspx to

http://myserver/MyApplication/(123456789ABCDEFG)/default.aspx. In

this case, 123456789ABCDEFG represents the current user's session token. A different

user browsing the site at the same time would receive a completely different session

token, resulting in a different URL, such as

http://myserver/MyApplication/(ZYXWVU987654321)/default.aspx.

While adding support for cookieless session state did improve the usability of ASP.NET

Web applications for users who would not accept cookies, it also had the side effect of

making those applications much more vulnerable to session hijacking attacks. Session

hijacking is basically a form of identity theft wherein a hacker impersonates a legitimate

user by stealing his session token. When the session token is transmitted in a cookie, and

the request is made on a secure channel (that is, it uses SSL), the token is secure.

However, when the session token is included as part of the URL, it is much easier for a

hacker to find and steal it. By using a network monitoring tool (also known as a “sniffer”)

or by obtaining a recent request log, hijacking the user’s session becomes a simple matter

of browsing to the URL containing the stolen unique session token. The Web application

has no way of knowing that this new request with session token “123456789ABCDEFG”

is not coming from the original, legitimate user. It happily loads the corresponding

session state and returns the response back to the hacker, who has now effectively

impersonated the user.

The most effective way to prevent these session hijacking attacks is to force your Web

application to use cookies to store the session token. This is accomplished by setting the

cookieless attribute of the <sessionState> element to UseCookies or false. But

what about the users who do not accept cookies? Do you have to choose between making

your application available to all users versus ensuring that it operates securely for all

users? A compromise between the two is possible in ASP.NET 2.0. By setting the

cookieless attribute to AutoDetect, the application will store the session token in a

cookie for users who accept them and in the URL for those who won’t. This means that

only the users who use cookieless tokens will still be vulnerable to session hijacking.

That's often acceptable, given the alternative—that users who deny cookies wouldn't be

able to use the application at all. It is ironic that many users disable cookies because of

privacy concerns when doing so can actually make them more prone to attack.

Some of the most common and dangerous application security vulnerabilities that exist in

ASP.NET Web-based applications come not from the C# or VB.NET code that make up

its pages and service methods, but instead from the XML code that makes up its

Web.config files. Incorrect configurations can open Web sites to application security

holes such as session hijacking, Cross-Site Scripting attacks, and even allow the

disclosure of private data to attackers.

An additional problem is that Web.config files were designed to be changed at any time,

even after the Web-based applications are in production. A well-intentioned system

administrator could inadvertently get around application security measures and open the

Web site to attack just by modifying the configuration file. And because .NET

configuration files operate in a hierarchical manner, a single change to the global

Machine.config file could affect every Web site on the entire network.

Part one of this article listed five of the most serious configuration vulnerabilities that are

applicable to any ASP.NET Web-based applications. This part will focus on

authentication and authorization application security issues, and detail another five

vulnerabilities commonly found in ASP.NET Web-based applications using Forms

authentication. It will also provide some best practices for application security, including

locking down your configuration files to ensure that they are not unintentionally modified

by well-meaning (but uninformed) programmers or administrators.

6. Cookieless Authentication Enabled

Just as in the “Cookieless Session State Enabled” vulnerability discussed in part one,

enabling cookieless authentication in your Web-based applications can lead to session

hijacking and problems with application security.

Vulnerable configuration:

<system.web>

Secure configuration:

<system.web>

When a session or authentication token appears in the request URL rather than in a secure

cookie, an attacker with a network monitoring tool can get around application security,

easily take over that session, and effectively impersonate a legitimate user. However,

session hijacking has far more serious consequences for application security after a user

has been authenticated. For example, online shopping sites generally utilize Web-based

applications that allow users to browse without having to provide an ID and password.

But when users are ready to make a purchase, or when they want to view their order

status, they have to login and be authenticated by the system. After logging in, sites

provide access to more sensitive data, such as a user's order history, billing address, and

credit card number. Attackers hijacking this user’s session before authentication can't

usually obtain much useful information. But if the attacker hijacks the session after

authentication, all that sensitive information could be compromised.

The best way to prevent session hijacking with Web-based applications is to disable

cookieless authentication and force the use of cookies for storing authentication tokens.

This application security measure is added by changing the cookieless attribute of the

<forms> element to the value UseCookies.

7. Failure to Require SSL for Authentication Cookies

Web-based applications use the Secure Sockets Layer (SSL) protocol to encrypt data

passed between the Web server and the client. Using SSL for application security means

that attackers using network sniffers will not be able to interpret the exchanged data.

Rather than seeing plaintext requests and responses, they will see only an indecipherable

jumble of meaningless characters.

You can require the forms authentication cookie from your Web-based applications to

use SSL by setting the requireSSL attribute of the <forms> element to true.

Vulnerable configuration:

<system.web>

Secure configuration:

<system.web>

The previous section discussed the importance of transmitting the authentication token in

a cookie, rather than embedding it in the request URL. However, disabling cookieless

authentication is just the first step towards securing the authentication token. Unless

requests made to the Web server are encrypted, a network sniffer will still be able to read

the authentication token from the request cookie. An attacker would still be able to hijack

the user’s session.

At this point, you might be wondering why it is necessary with application security to

disable cookieless authentication, since it is very inconvenient for users who won’t accept

cookies, and seeing as how the request still has to be sent over SSL. The answer is that

the request URL is often persisted regardless of whether or not it was sent via SSL. Most

major browsers save the complete URL in the browser history cache. If the history cache

were to be compromised, the user’s login credentials would be as well. Therefore, to truly

secure the authentication token, you must require the authentication token to be stored in

a cookie, and use SSL to ensure that the cookie be transmitted securely.

By setting the requireSSL attribute of the <forms> element to true, ASP.NET Webbased

applications will use a secure connection when transmitting the authentication

cookie to the Web server. Note that IIS requires additional configuration steps to support

SSL. You can find instructions to configure SSL for IIS on MSDN

(http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/56bdf9

77-14f8-4867-9c51-34c346d48b04.mspx?mfr=true).

8. Sliding Expiration Used

All authenticated ASP.NET sessions have a timeout interval to protect the application

security. The default timeout value is 30 minutes. So, 30 minutes after a user first logs

into any of these Web-based applications, he will automatically be logged out and forced

to re-authenticate his credentials.

Vulnerable configuration:

<system.web>

Secure configuration:

<system.web>

The slidingExpiration setting is an application security measure used to reduce risk

to Web-based applications in case the authentication token is stolen. When set to false,

the specified timeout interval becomes a fixed period of time from the initial login, rather

than a period of inactivity. Attackers using a stolen authentication token have, at

maximum, only the specified length of time to impersonate the user before the session

times out. Because typical attackers of these Web-based applications have only the token,

and don't really know the user's credentials, they can't log back in as the legitimate user,

so the stolen authentication token is now useless and the application security threat is

mitigated. When sliding expiration is enabled, as long as an attacker makes at least one

request to the system every 15 minutes (or half of the timeout interval), the session will

remain open indefinitely. This gives attackers more opportunities to steal information and

cause other mischief in Web-based applications.

To avoid this application security issue altogether, you can disable sliding expiration by

setting the slidingExpiration attribute of the <forms> element to false.

9. Non-Unique Authentication Cookie Used

Over the last few sections, I hope I have successfully demonstrated the importance of

application security and of storing your application’s authentication token in a secure

cookie value. But a cookie is more than just a value; it is a name-value pair. As strange as

it seems, an improperly chosen cookie name can create an application security

vulnerability just as dangerous as an improperly chosen storage location.

Vulnerable configuration:

<system.web>

Secure configuration:

<system.web>

The default value for the name of the authentication cookie is .ASPXAUTH. If you have

only one Web-based application on your server, then .ASPXAUTH is a perfectly secure

choice for the cookie name. In fact, any choice would be secure. But, when your server

runs multiple ASP.NET Web-based applications, it becomes critical to assign a unique

authentication cookie name to each application. If the names are not unique, then users

logging into any of the Web-based applications might inadvertently gain access to all of

them. For example, a user logging into the online shopping site to view his order history

might find that he is now able to access the administration application on the same site

and change the prices of the items in his shopping cart.

The best way to ensure that all Web-based applications on your server have their own set

of authorized users is to change the authentication cookie name to a unique value.

Globally Unique Identifiers (GUIDs) are excellent choices for application security since

they are guaranteed to be unique. Microsoft Visual Studio helpfully includes a tool that

will automatically generate a GUID for you. You can find this tool in the Tools menu

with the command name “Create GUID”. Copy the generated GUID into the name

attribute of the <forms> element in the configuration file.

10. Hardcoded Credentials Used

Vulnerable configuration:

<system.web>

<forms>

…

</credentials>

</forms>

Secure configuration:

<system.web>

<forms>

</forms>

A fundamental difficulty of creating software is that the environment in which the

application will be deployed is usually not the same environment in which it is created. In

a production environment, the operating system may be different, the hardware on which

the application runs may be more or less powerful, and test databases are replaced with

live databases. This is an issue for creating Web-based applications that require

authentication because developers and administrators often use test credentials to test the

application security. This begs the question: Where do the test credentials come from?

For convenience, to avoid forcing developers from spending time on creating a credential

store used solely for test purposes (and which would subsequently be discarded when the

application went to production), Microsoft added a section to the Web.config file that you

can use to quickly add test users to Web-based applications. For each test user, the

developer adds an element to the configuration file with the desired user ID and password

as shown below:

<forms>

</credentials>

</forms>

</authentication>

While undeniably convenient for development purposes, this was never intended for use

in a production environment. Storing login credentials in plaintext in a configuration file

is simply not secure. Anyone with read access to the Web.config file could access the

authenticated Web application. It is possible to store the SHA-1 or MD5 hash of the

password value, rather than storing the password in plaintext. This is somewhat better,

but it is still not a secure solution. Using this method, the user name is still not encrypted.

First, providing a known user name to a potential attacker makes it easier to perform a

brute force attack against the system. Second, there are many reverse-lookup databases of

SHA-1 and MD5 hash values available on the Internet. If the password is simple, such as

a word found in a dictionary, then it is almost guaranteed to be found in one of these hash

dictionaries.

The most secure way to store login credentials is to not store them in the configuration

file. Remove the <credentials> element from your Web.config files in production

applications.

You’re Not Out of the Woods Yet

Now that you’ve finished reading the top-ten list, and you've checked your configuration

settings, your applications are secure forever, right? Not just yet. Web.config files operate

in a hierarchical inheritance manner. Every Web.config file inherits values from any

Web.config file in a parent directory. That Web.config file in turn inherits values from

any Web.config file in its parent directory, and so on. All Web.config files on the system

inherit from the global configuration file called Machine.config located in the .NET

framework directory. The effect of this is that the runtime behavior of your application

can be altered simply by modifying a configuration file in a higher directory.

This can sometimes have unexpected consequences. A system administrator might make

a change in a configuration file in response to a problem with a completely separate

application, but that change might create a security vulnerability in your application. For

example, a user might report that he is not able to access the application without enabling

cookies in his browser. The administrator, trying to be helpful, modifies the global

configuration file to allow cookieless authentication for all applications.

To keep your application-specific settings from being unexpectedly modified, the

solution is to never rely on default setting values. For example, debugging is disabled by

default in configuration files. If you’re examining the configuration file for your

application and you notice that the debug attribute is blank, you might assume that

debugging is disabled. But it may or may not be disabled—the applied value depends on

the value in parent configuration settings on the system. The safest choice is to always

explicitly set security-related values in your application’s configuration.

Ultimately, securing a Web application requires the efforts and diligence of many

different groups, from quality assurance to security operations. However, the developer

who codes the application itself has an inherent responsibility to instill security into the

application from the beginning of the development process. By making securityconscious

decisions from the beginning, developers can create applications that users can

trust with their confidential information and that are capable of withstanding attacks

launched by hackers. As I’ve tried to show here, sometimes that process can be as simple

as making the right decisions when configuring your application.

About the Author

Bryan Sullivan is a development manager at SPI Dynamics, a Web application security

products company. Bryan manages the DevInspect and QAInspect Web security

products, which help programmers maintain application security throughout the

development and testing process. He has a bachelor’s degree in mathematics from

Georgia Tech and 12 years of experience in the information technology industry. Bryan

is currently coauthoring a book with noted security expert Billy Hoffman on Ajax

security, which will be published in summer 2007 by Addison-Wesley.

Merry Christmas!

2010-12-24T03:01:00.000-08:00

We wish you a Merry Christmas,

We wish you a Merry Christmas,
We wish you a Merry Christmas,
And a Happy New Year!
Good tidings we bring

To you and your kin;
Good tidings for Christmas And a Happy New Year!
Now bring us some figgy pudding,

Now bring us some figgy pudding,
Now bring us some figgy pudding,
And bring some right here!
Good tidings we bring

To you and your kin;
Good tidings for Christmas
And a Happy New Year!
For we all like a figgy pudding,

We all like a figgy pudding,
We all like a figgy pudding,
So bring it out here!
Good tidings we bring

To you and your kin;
Good tidings for Christmas
And a Happy New Year!
And we won't go till we've got some,

We won't go till we've got some,
We won't go till we've got some,
So bring some right here!
Good tidings we bring

To you and your kin;
Good tidings for Christmas
And a Happy New Year!

Wildlife In India

2010-12-20T20:47:00.000-08:00

India is home to a rich diversity of wildlife supplemented by an equally rich variety of flora and fauna. The sight and sounds of a majestic elephant, a peacock’s dance, the stride of a camel, the roar of a tiger are unparalleled experiences in themselves. Watching birds and animals in their natural habitats is an experience in itself.

The country offers immense opportunities for wildlife tourism. The immense heritage of wildlife in India comprises of more than 70 national parks and about 400 wildlife sanctuaries including the bird sanctuaries.
A paradise for the nature lovers, these forest areas are also crucial for the conversation of the endangered species like the Leopard, Lion, Asiatic Elephant, the Bengal tiger and Siberian Crane. Spread across the length and breadth of India, these reserves and forest areas, right from the Ranthambore National Park in Rajasthan to the Hazaribagh Wildlife Sanctuary in Bihar, from the foothills of Himalayas, the Jim Corbett National Park to six national parks in Andaman; the Indian Wildlife circuit is an Incredible treat, unmatched by any other experience.
Elephant, Deer, Panther, Wild buffalo, Wild ass, the one horned Rhinoceros, Porcupine, Snow leopards etc are some of the animals you can sport in The Himalayan region.

India harbours eighty percent of the entire population of the one horned rhinoceros in the world. The Kaziranga Game Sanctuary is an ideal habitat for the rhino and a popular destination with the naturalists and environmentalists as well as the wildlife traveller.
The Great Indian Bustard and blackbuck of the Karera Sanctuary also attract a lot of tourists. The Madhav National Park originally called the Shivpuri National Park is another rich habitat for the wildlife in close proximity to the historical town of Gwalior and being close to a often visited cultural and heritage destination enjoys its fare share of tourism inflow. The Corbett National Park one of the most popular National Parks in the northern region for the wildlife enthusiast as well as the holiday makers is changing the way wildlife tourism. These National Parks and Wildlife Sanctuaries are promoters of wildlife tourism in India.

India has its fair share of Tiger Reserves. India’s National Animal, the tiger happens to be a symbol of strength and speed. India boasts of two-dozen Tiger Reserves. The fastest mammal on Earth, the tiger happens to be the joy and pride of India. The Royal Bengal tiger is amongst the most majestic species of the tiger. Sixty percent of the total population of the wild tigers in the world resides in India. Amongst the best-known tiger reserves in India is the Bandhavgarh in Madhya Pradesh. It is often referred to as the crown in the wildlife heritage of India. Tourists at Bandhavgarh can spot Royal Bengal Tigers, cheetals, leopard, gaur, sambhar, and many more faunal species. The highly successful Project Tiger has shown once again that man can only undo in small ways the loss and destruction of natural habitat due to continuous growth and expansion of the population.
Indian wildlife has its share of native birds along with the migratory birds. Several hundred species of birds can be spotted across India. The Himalayan region is well known to be the natural habitat for the Pheasant, griffon vulture and ravens. The Keoladeo Ghana National Park popularly known as the Bharatpur Bird Sanctuary in the Indian state of Rajasthan, in close proximity of Delhi, is home to indigenous water birds, waterside birds, migratory water birds, land migratory birds, and domestic land species. Tourists from far and wide are attracted to the Bird Sanctuary. At the Dudhwa wildlife reserve migratory birds like Egrets, herons, storks and cormorants share space with the ducks, gees and teals. The region of Andaman is home for the rare species of birds like the Narcondum hornbill, Nicobar Pigeon and the Megapode.