Stepping Up 2008

You know you’ve got the skills to do the job, but how do you convince potential customers and employers?

To broaden the vision of the career-minded professional in you, we have arranged a seminar on: - Planning better careers in IT - Getting the most out of potential customers and employers - New Generation Certifications and how to get the most out of them - Increased service excellence as the driver of IT policy - Attend the in-person seminar by industry leaders and experts! Get answers to the questions you have always wanted to ask.       MARK YOUR CALENDAR AND REGISTER NOW  FOR FREE!   Click at your city - Mumbai Bangalore Hyderabad     Chennai Delhi

WSE 2.0 Vs WSE 3.0

This is probably one of the main concerns for people involved in the development of web services using WSE.
Unfortunately, WSE 3.0 was designed from the beginning to be compatible at wire level with Indigo and therefore it doesn't interoperate well with WSE 2.0.
To be clear, "Wire compatible" means equivalent messages.
I wrote this post to provide some necessary points to obtain interoperability between both versions.

WS-Security xx specs

At this moment, there are two available versions of this specification, 1.0 and 1.1 (Also called WS-Security extensions).
WSE 2.0 only implements the first version whereas WSE 3.0 uses features of both versions (such as signature confirmation and key derivation).
Both endpoints, the client and the server should use features provided only by WS-Security 1.0.

Secure conversation

Secure Conversation is a special feature provided by WSE, in which client and server negotiate a session token to protect the communication for a specific period of time. This feature decrease the response time because the token negotiation happens once compared to other turn-key scenarios where the negotiation is done for each message. (This feature is really important when the client and the server interchange many messages during a period of time).
The SecureContext token used in WSE 3.0 is not compatible with WSE 2.0 since it was modified to support new features like "Stateful secure context tokens".

WS-Addressing xx specs

WSE 3.0 uses a newer version of this specification (The same as Indigo) and therefore the messages produced by both versions are not compatible.
There is not a good way to fix this problem, but probably a SoapFilter to update the addressing headers can be a solution.

Algorithm suite

WSE 3.0 uses by default the same algorithm suite as Indigo, AES256 for symmetric encryption and RSA-OAEP for key wrap. On the other hand, WSE 2.0 uses AES128 and RSA-15.
You will have to update the configuration settings in both endpoints in order to use the same algorithm suite.

Using the same algorithm suitein WSE 2.0 and WSE 3.0

Default algorithms in WSE 3.0

WSE 2.0 and 3.0, both provide AES128 + RSA 1.5 as default algorithms for symmetric encryption and key-wrap.
However, AES256 + RSA-OAEP are always recommended for these purposes, and Indigo will ship with that combination as default.

In WSE 2.0, these algorithms could be changed adding some settings in the configuration file:

<microsoft.web.services2>
...
  <security>
  ....
    <binarySecurityTokenManager
      valueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3">
      <sessionKeyAlgorithm name="TripleDES"/>   <!-- add this to switch to TripleDes from default AES128 -->
      <keyAlgorithm name="RSAOAEP"/>  <!-- add this to switch to RSA-OEAP from default RSA15 -->
    </binarySecurityTokenManager>
  </securityç>
...
<microsoft.web.services2>

These settings don't affect in the same way to WSE 3.0 because it implements some changes in the code used to secure messages. The security assertions
shipped within WSE 3.0 use different tokens to secure messages, they don't use an X509 security token anymore, instead they use derived tokens.

EncryptedToken: Usually, this token is used by the security assertions to sign and encrypt messages.

DerivedKeyToken: Only used when the flag "DeriveKeys" is on.

SecureContextToken: Only used in secure conversations. (When the flag "establishSecurityContext" is on)

The following configuration shows how to override the default algorithm used by these tokens:

<microsoft.web.services3>
  <security>
<binarySecurityTokenManager>
  <add
    type="Microsoft.Web.Services3.Security.Tokens.X509SecurityTokenManager, Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"
   valueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3">
    <keyAlgorithm name="RSAOAEP"/>
  </add>
</binarySecurityTokenManager>
<securityTokenManager>
  <add localName="EncryptedKey"
   type="Microsoft.Web.Services3.Security.Tokens.EncryptedKeyTokenManager, Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"
    namespace="http://www.w3.org/2001/04/xmlenc#">
    <keyAlgorithm name="AES256"/>
  </add>
  <add localName="DerivedKeyToken">
    type="Microsoft.Web.Services3.Security.Tokens.DerivedKeyTokenManager, Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"
    namespace="http://schemas.xmlsoap.org/ws/2005/02/sc">
    <keyAlgorithm name="AES256"/>
  </add>
  <add localName="SecurityContextToken"
    type="Microsoft.Web.Services3.Security.Tokens.SecurityContextTokenManager, Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"
    namespace="http://schemas.xmlsoap.org/ws/2005/02/sc">
    <keyAlgorithm name="AES256"/>
  </add>
</securityTokenManager>
</security>
</microsoft.web.services3>

Securing Web Services using WSE 3.0

Links

• patterns & practices
• Web Services Security
• Web Services Security QuickStarts
• Web Services Security Community Workspace
• Slides from this webcast

If you liked this episode check out these...

• ARCast - Securing Web Services with Kerberos Tokens in WSE 3.0 (Part 2)
• ARCast - Securing Web Services with X.509 Certificates in WSE 3.0 (Part 1)
• ARCast - Securing Web Services with X.509 Certificates in WSE 3.0 (Part 2)
• ARCast - Web Services Security Patterns Post Game Show
• ARCast - Web Services Security Patterns (Part 1)
• ARCast - Web Services Security Patterns (Part 2)

Securing Web Services with WSE 2.0

Requiring UsernameTokens
Authentication and Authorization
Implementing a UsernameTokenManager
Requiring Signatures
Using DerivedKeyTokens
Requiring Encryption
Signing and Encrypting with X.509 Tokens
Automating Security with Policy
Note on the UsernameTokenManager
Where Are We?

Read the article for complete view : http://msdn.microsoft.com/msdnmag/issues/04/10/ServiceStation/

Debug classic ASP code in Visual Studio 2005

Go to Debug > Attach to Process ...

Select dllhost.exe and click Select... button. Select "Script" checkbox from the dialogue box.

Click OK and ultimately click Attach.

NOTE: Debugging will not work unless your IIS is enabled for .asp debugging. To do that go to your IIS > Home Directory > Configuration > Debugging and check both checkboxes (Enable ASP server-side debugging and Enable ASP client-side debugging)

Using Regular Expressions

 

How To: Use Regular Expressions to Constrain Input in ASP.NET

This How To shows how you can use regular expressions within ASP.NET applications to constrain untrusted input. Regular expressions are a good way to validate text fields such as names, addresses, phone numbers, and other user information. You can use them to constrain input, apply formatting rules, and check lengths. To validate input captured with server controls, you can use the RegularExpressionValidator control. To validate other forms of input, such as query strings, cookies, and HTML control input, you can use the System.Text.RegularExpressions.Regex class.

This How To shows how you can use regular expressions within ASP.NET applications to constrain untrusted input.

 

If you make unfounded assumptions about the type, length, format, or range of input, your application is unlikely to be robust. Input validation can become a security issue if an attacker discovers that you have made unfounded assumptions. The attacker can then supply carefully crafted input that compromises your application by attempting SQL injection, cross-site scripting, and other injection attacks. To avoid such vulnerability, you should validate text fields (such as names, addresses, tax identification numbers, and so on) and use regular expressions to do the following:

• Constrain the acceptable range of input characters.
• Apply formatting rules. For example, pattern-based fields, such as tax identification numbers, ZIP Codes, or postal codes, require specific patterns of input characters.
• Check lengths.

Regular expression support is available to ASP.NET applications through the RegularExpressionValidator control and the Regex class in the System.Text.RegularExpressions namespace.

Using a RegularExpressionValidator Control

If you capture input by using server controls, you can use the RegularExpressionValidator control to validate that input. You can use regular expressions to restrict the range of valid characters, to strip unwanted characters, and to perform length and format checks. You can constrain the input format by defining patterns that the input must match.

To validate a server control's input using a RegularExpressionValidator

1. Add a RegularExpressionValidator control to your page.
2. Set the ControlToValidate property to indicate which control to validate.
3. Set the ValidationExpression property to an appropriate regular expression.
4. Set the ErrorMessage property to define the message to display if the validation fails.

The following example shows a RegularExpressionValidator control used to validate a name field.

Copy Code

<%@ language="C#" %>
<form id="form1" runat="server">
    <asp:TextBox ID="txtName" runat="server"/>
      <asp:Button ID="btnSubmit" runat="server" Text="Submit" />
    <asp:RegularExpressionValidator ID="regexpName" runat="server"     
                                    ErrorMessage="This expression does not validate." 
                                      ControlToValidate="txtName"     
                                    ValidationExpression="^[a-zA-Z'.\s]{1,40}$" />
</form>
  

The regular expression used in the preceding code example constrains an input name field to alphabetic characters (lowercase and uppercase), space characters, the single quotation mark (or apostrophe) for names such as O'Dell, and the period or dot character. In addition, the field length is constrained to 40 characters.

Using ^ and $

Enclosing the expression in the caret (^) and dollar sign ($)markers ensures that the expression consists of the desired content and nothing else. A ^ matches the position at the beginning of the input string and a $ matches the position at the end of the input string. If you omit these markers, an attacker could affix malicious input to the beginning or end of valid content and bypass your filter.

Using the Regex Class

If you are not using server controls (which means you cannot use the validation controls) or if you need to validate input from sources other than form fields, such as query string parameters or cookies, you can use the Regex class within the System.Text.RegularExpressions namespace.

To use the Regex class

1. Add a using statement to reference the System.Text.RegularExpressions namespace.
2. Call the IsMatch method of the Regex class, as shown in the following example.
   Copy Code

   // Instance method:
   Regex reg = new Regex(@"^[a-zA-Z'.]{1,40}$");
   Response.Write(reg.IsMatch(txtName.Text));
   
   // Static method:
    if (!Regex.IsMatch(txtName.Text, 
                       @"^[a-zA-Z'.]{1,40}$"))
   {
     // Name does not match schema
   }
     

For performance reasons, you should use the static IsMatch method where possible to avoid unnecessary object creation.

The following example shows how to use a regular expression to validate a name input through a regular client-side HTML control.

Copy Code

<%@ Page Language="C#" %>

<html  >
  <body>
    <form id="form1" method="post" action="HtmlControls.aspx">
          Name:
        <input name="txtName" type="text" />
        <input name="submitBtn" type="Submit" value="Submit"/>
    </form>
  </body>
  </html>

<script runat="server">

  void Page_Load(object sender, EventArgs e)
  {
    if (Request.RequestType == "POST")
    {
      string name = Request.Form["txtName"];
        if (name.Length > 0)
      {
        if (System.Text.RegularExpressions.Regex.IsMatch(name, 
                                           "^[a-zA-Z'.]{1,40}$"))
          Response.Write("Valid name");
          else
          Response.Write("Invalid name");
      }
    }
  }

</script>
  

Use Regular Expression Comments

Regular expressions are much easier to understand if you use the following syntax and comment each component of the expression by using a number sign (#). To enable comments, you must also specify RegexOptions.IgnorePatternWhitespace, which means that non-escaped white space is ignored.

Copy Code

Regex regex = new Regex(@"
                        ^           # anchor at the start
                       (?=.*\d)     # must contain at least one numeric character
                         (?=.*[a-z])  # must contain one lowercase character
                       (?=.*[A-Z])  # must contain one uppercase character
                       .{8,10}      # From 8 to 10 characters in length
                         \s           # allows a space 
                       $            # anchor at the end", 
                       RegexOptions.IgnorePatternWhitespace);
  

Common Regular Expressions

Some common regular expressions are shown in Table 1.

Table 1. Common Regular Expressions

Field	Expression	Format Samples	Description
Name	^[a-zA-Z''-'\s]{1,40}$	John Doe O'Dell	Validates a name. Allows up to 40 uppercase and lowercase characters and a few special characters that are common to some names. You can modify this list.
Social Security Number	^\d{3}-\d{2}-\d{4}$	111-11-1111	Validates the format, type, and length of the supplied input field. The input must consist of 3 numeric characters followed by a dash, then 2 numeric characters followed by a dash, and then 4 numeric characters.
Phone Number	^[01]?[- .]?(\([2-9]\d{2}\)|[2-9]\d{2})[- .]?\d{3}[- .]?\d{4}$	(425) 555-0123 425-555-0123 425 555 0123 1-425-555-0123	Validates a U.S. phone number. It must consist of 3 numeric characters, optionally enclosed in parentheses, followed by a set of 3 numeric characters and then a set of 4 numeric characters.
E-mail	^([0-9a-zA-Z]([-.\w]*[0-9a-zA-Z])*@([0-9a-zA-Z][-\w]*[0-9a-zA-Z]\.)+[a-zA-Z]{2,9})$	someone@example.com	Validates an e-mail address.
URL	^(ht|f)tp(s?)\:\/\/[0-9a-zA-Z]([-.\w]*[0-9a-zA-Z])*(:(0-9)*)*(\/?)([a-zA-Z0-9\-\.\?\,\'\/\\\+&%\$#_]*)?$	http://www.microsoft.com	Validates a URL
ZIP Code	^(\d{5}-\d{4}|\d{5}|\d{9})$|^([a-zA-Z]\d[a-zA-Z] \d[a-zA-Z]\d)$	12345	Validates a U.S. ZIP Code. The code must consist of 5 or 9 numeric characters.
Password	(?!^[0-9]*$)(?!^[a-zA-Z]*$)^([a-zA-Z0-9]{8,10})$		Validates a strong password. It must be between 8 and 10 characters, contain at least one digit and one alphabetic character, and must not contain special characters.
Non- negative integer	^\d+$	0 986	Validates that the field contains an integer greater than zero.
Currency (non- negative)	^\d+(\.\d\d)?$	1.00	Validates a positive currency amount. If there is a decimal point, it requires 2 numeric characters after the decimal point. For example, 3.00 is valid but 3.1 is not.
Currency (positive or negative)	^(-)?\d+(\.\d\d)?$	1.20	Validates for a positive or negative currency amount. If there is a decimal point, it requires 2 numeric characters after the decimal point.

Additional Resources

For more information, see the regular expression tutorial at http://www.regular-expressions.info/tutorial.html [ http://www.regular-expressions.info/tutorial.html ] .