Showing posts with label Security. Show all posts
Showing posts with label Security. Show all posts

Friday, February 22, 2013

Safe forms without captcha - hybrid approach

Captcha is very annoying for users. How can we make safe forms without captcha?

Today's popular approaches are:
  • CSS technique. Idea about this is to create invisible field(hidden via CSS) in form. Silly spambots don't know that people can't see this field and fill it out. So, on server side you should make sure that this field is empty. 
  • Javascript technique. Idea about this is to generate and fill out some field using javascript. Silly spambots can't process javascript. So, on server side you should make sure that this field is not empty. This approach is good, but it has big disadvantage: if real user has javascript turned off he will not get this generated field, so he will not fill it out. Real user with disabled javascript = Silly spam bot. 
Problem with this approaches: What if spam bot is Not Silly ?

First approach is great in its simplicity, but i think that it is more easily for spam bots to overcome this obstacle, than second one. Javascript processing requires more brains in spambot head. So i like second approach more, but i do not like the fact that poor people with disabled javascript will suffer.

I want not to bother user with captcha if he has javascript enabled. But if poor user has javascript disabled, he will get captcha(and spambot will get captcha too).

So, my hybrid approach is to use captcha block(captcha image+ input field) wrapped in <noscript/> tags. And then use javascript to hide captcha block, remove <noscript/> tags, and fill out captcha with valid value.

As result, we have captcha that is showing for users that have javascript disabled(as well as spambots). If user has javascript turned on, then captcha will be hidden and filled out using javascript. 
On server side we just check if captcha is valid- it is not matter for us whether user has javascript enabled!




Monday, November 12, 2012

SSO in multiple ASP.NET applications under the same domain

Suppose you have two different web applications under the same domain. For example:

First web application(ASP.NET Web Forms): http://example.com/
Second web application(ASP.NET MVC): http://example.com/admin/

Both web applications use ASP.NET Forms authentication.

How to make possible to authenticate in one web-application and be authenticated in another?

The answer is to use same machineKey configuration and authentication cookie name in both web applications.

Example of first web application(ASP.NET Web Forms) config section:
 <system.web>  
  <machineKey validationKey="6366D9EDF5591718A1A69557F106AFC16A8A184159028364814BD3B9D48941832E7310C0386DAD406AD04337B4B57D1772430233FCB82E265635DE5E35FF3C4F" decryptionKey="76D34CAEA4614B2EBFB0E20819CFE744389ADCC511D94C8CEA7DA6517C9D0E68" validation="SHA1" decryption="AES" />  
  <authentication mode ="Forms" >  
    <forms name =".AUTH" loginUrl= "~/Login.aspx" />  
   </authentication>   
 </system.web>  

Example of second web application(ASP.NET MVC) config section:
 <system.web>  
  <machineKey validationKey="6366D9EDF5591718A1A69557F106AFC16A8A184159028364814BD3B9D48941832E7310C0386DAD406AD04337B4B57D1772430233FCB82E265635DE5E35FF3C4F" decryptionKey="76D34CAEA4614B2EBFB0E20819CFE744389ADCC511D94C8CEA7DA6517C9D0E68" validation="SHA1" decryption="AES" />  
  <authentication mode ="Forms" >  
    <forms name =".AUTH" loginUrl= "~/Authentication/Login " />  
   </authentication>  
 </system.web>  

You can generate unique machineKey for your applications here: http://aspnetresources.com/tools/machineKey

Friday, November 2, 2012

Is enabling Double Escaping dangerous in ASP.NET?

Let's say we want to use plus sign in URL paths in our ASP.NET application.

For example: http://example.com/news/tag1+tag2/

If we try to request this URL, IIS(in fact, Request Filtering Module) will reject request with 404 error.

The only chance for me to do this was the following section in Web.config:
 <system.webServer>   
  <security>  
    <requestFiltering allowDoubleEscaping="true"/>  
  </security>  
 </system.webServer>  

With this setting everything works fine, except for the fact that we allow double escaping for all URLs in our application. So, is enabling double escaping dangerous?

Allowing double escaping points IIS to forward request to ASP.NET application, even if there is still encoded fragments in URL after first decoding.

Many would say that it's not big deal, but i decided not to risk, so i changed "+" delimiter in URL to "_" and removed section from Web.config.

So, my URLs look like:
http://example.com/news/tag1_tag2/