URL Follower Tool

Today we released a tool that will quickly tell you how many redirects a URL does until it lands at its final page – URL Follower Each request contains information such as the HTTP headers and page content. It’s sort of a mini web debugger except the pages are never rendered/executed. The main purpose of the tool is to explore links which you feel are not safe without having to click the link. Just copy and paste the link into the text box and hit Go.

For example try out this URL: http://goo.gl/lCJBR (results)

You can see in the results that http://goo.gl/lCJBR does a permanent redirect to http://www.numina.net

URL Follower results

SQL Server Reporting Services Single Sign On

I am excited to announce that we now have a solution for integrating the Numina Application Framework with SQL Server Reporting Services (including Report Builder). Bringing single sign on capability to SSRS means that you can continue accessing SSRS with your domain credentials and allow others, from outside of your organization, to access reports as well.

Controlling security to reports remains within SSRS but is tied to the users’ application permissions. Our solution is accomplished through SSRS security extensions which talk to the Numina Application Framework Service.

Contact us today if you would like to hear more about authentication with SQL Server Reporting Services.

Introducing the Numina Workflow Manager

The Numina Workflow Manager will let you create a workflow for any application. This is accomplished by creating workflow statuses and setting the next statuses for each. You can also create work queues and assign access to each. The real usefulness of the Workflow Manager lies within the API and the applications that apply workflow.

I think it is best to explain how it works through an example. Lets pretend that we have a website where customers can order items. A typical scenario might look like this:

  1. User places order using an online order form.
  2. Website saves order and sets the initial status to Processing.
  3. A person from the Finance department sees the order in their queue and processes the payment. If it goes through then they will move the order to the Charged status.
  4. At this point the Floor Crew can pick up the order in their queue and move it to the Packaging status. They will gather the items needed and print the shipping label. Once the packaging is done they will move the order to the Ready for Shipment status.
  5. The Customer Service department can now see the order in their queue. They will deal with handling the order from now until the customer gets it.
  6. Some time later that day FedEx will come and pick up the package. When this happens the status will move to Shipped.
Our workflow for something like this very simple. See the flow chart below…

 

 

Each circle and box represents a different workflow status and each color represents a different queue. We will also allow Managers to see all queues, which will allow them to see all orders. We can simulate this workflow by adding all of the statuses in the Workflow Manager and then setting the next workflow status for each, like this:

  1. Processing
    • Next Statuses:
      1. Hold
      2. Charged
      3. Void
  2. Charged
    • Next Statuses:
      1. Packaging
      2. Void
  3. Packaging
    • Next Statuses:
      1. Ready For Shipment
      2. Void
  4. Ready For Shipment
    • Next Statuses:
      1. Shipped
  5. Hold
    • Next Statuses:
      1. Processing
  6. Void
    • No Next Statuses
  7. Shipped
    • No Next Statuses

Then we will create our queues and assign the appropriate statuses. We’ll also assign which groups and users have access to each queue.

  1. Finance Queue
    • Can view orders with status:
      1. Processing
      2. Hold
      3. Charged
      4. Void
    • Groups who can see this queue:
      1. Finance Department
      2. Managers
  2. Packing Queue
    • Can view orders with status:
      1. Charged
      2. Packaging
    • Groups who can see this queue:
      1. Floor Crew
      2. Managers
  3. Customer Service Queue
    • Can view orders with status:
      1. Ready For Shipment
      2. Shipped
      3. Void
    • Groups who can see this queue:
      1. Customer Service Department
      2. Managers

This is a basic workflow but I think it illustrates what you can do with the Workflow Manager. Like previously mentioned, all you are doing is creating statuses and defining which statuses you can go to. Queues are a mapping between statuses and users. They determine what each user can see. This same approach can be applied to create a much more intricate workflow as well.

How Validation Tickets Work

When you want to access the Numina WCF service, or other services you have secured using the Framework, you are required to first get a Validation Ticket and supply it with each method call. But how does this work and why is it secure?

When you request a Validation Ticket you submit your domain name, user name, and password. Your credentials are authenticated the same way as users logging into the front-end login site. You also submit the URL of the application you want a validation ticket for. After authentication we check to see if you are authorized to use the application. If so, we generate the Validation Ticket and return it to you.

The Validation Ticket is made up of three main things: an Application ID, a (service) User ID, and a Security Token. When we generate the ticket, we take the Application ID and User ID to come up with the Security Token. When you get the ticket back you have to save it (so that you don’t have to keep requesting tickets / prevent extra overhead) and send it back with each secured method call.

Upon calling a secured method we inspect your ticket and re-generate the Security Token from the supplied Application ID and User ID. If the token you passed back to us matches the generated token then we do a final check to make sure that the User ID is valid and is still authorized to use the service. If both of these checks pass then we allow the method to continue executing.

This is secure because only the Numina service can generate the correct Security Token. If you tamper with the Application ID or User ID a different token will be generated when making a secured call and cause it to fail. Alternatively if you modify the Security Token it will not match the generated token and also fail. The Security Token is generated using a strong cryptography algorithm which takes in a hash key. The hash key is secret and is never the same on any two installations.

Fight Spam with a Honeypot

Wikipedia describes a honeypot as “a trap set to detect, deflect, or in some manner counteract attempts at unauthorized use of information systems.” I have found the use of honeypots on web forms to be a nifty way of preventing spam. To do this, create a form field that will be visibly hidden.

<input type="text" name="Website" value="" style="display:none" />

I like to set the name attribute to something spam bots will want to fill in; and make it a habit not to use this name for anything else. I also don’t always end up putting the style=”display:none” attribute right on the input, but rather create a CSS class with this style and put it on a div around the input; to mask it’s purpose somewhat.

When a real user fills out your form they will not see this field, and the form submission will contain an empty “Website” value. Spam bots however, try to fill in as many fields as they can, and won’t pick up that this field is hidden and shouldn’t be filled in. If a submission comes through with a value for the “Website” field then you can almost guarantee it is a spam bot.

I have found one case where certain auto-form-filling browser plugins will try to populate hidden fields like this. Instead of throwing an error or faking a successful submission I tend to inform the user that they shouldn’t use the browser plugin to complete the form. That way they have a chance to refresh and submit the form again.

As a final note, this method should only be used to deter spam bots. If someone studies your form and finds this preventive measure in place it is easy to defeat – but it will work at preventing spam for those generic web crawling spam bots.

How Numina Application Framework Prevents CSRF Attacks

Suppose you visit a malicious website soon after logging into your bank website. Your session/cookie on the bank site might still be valid. If this is the case then the malicious website could perform a Cross Site Request Forgery (CSRF) attack, causing a form post to the bank website. Your browser would send the authentication cookie back to the bank site and appear to be making a request on your behalf, even though you did not intend to do so. For example, a malicious site could use this attack to transfer money from your bank account to theirs! Most banks protect against this so don’t feel worried.

The Numina Application Framework also prevents this attack. But how?

When a malicious site makes a form post to the bank site, it has to know all of the form data to send along in the request. So what if we add something that is required to make a form post? It has to be unique to the user and cannot be reproduced by a malicious site. Quite simply, we add the user’s Session ID. If the form value for this field doesn’t match the Session ID on the server, then we toss the request away.

As a secondary precaution we also check the referring URL. If a form post is made and the referring URL is not our own site, we will toss the request away.

Numina Application Framework Browser Security Updates

A number of browser security updates have been implemented in the Numina Application Framework and will be available in the next release. All of these browser security updates are Http Header related. This is what a typical header looks like:

HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/7.5
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-AspNet-Version: 4.0.30319
Set-Cookie: Numina.Framework.AuthCookie=somehash; path=/; secure; HttpOnly
Set-Cookie: Numina.Framework.AuthDomain=domain; expires=date; path=/; secure; HttpOnly
X-Powered-By: ASP.NET
Date: Mon, 22 Aug 2011 23:34:34 GMT
Content-Length: 136

Here is an explanation of each:

Set-Cookie: Secure
This tells the browser to only send cookies over a secure (SSL) connection. If the site happens to hit a page that is not SSL, then the cookie will not be sent.

Set-Cookie: HttpOnly
This prevents the cookie from being accessed by client side script.

Both of these cookie attributes help to prevent session hijacking by only sending cookies when appropriate.

X-Content-Type-Options: nosniff
This prevents “mime” based attacks. The header instructs the browser not to override the response content type. For example, some browsers try to be smart by deciding for themselves if the content is really is text/html or an image. So with the nosniff option, if the server says the content is text/html, then the browser needs to render it as text/html.

X-Frame-Options: SAMEORIGIN
This tells the browser to only render frame pages from the URL hosting the main page. This prevents Clickjacking attacks against the user. Clickjacking is a browser-based attack that tricks the user into clicking on one thing but then performs a different action, such as following a user on Twitter.

X-XSS-Protection: 1; mode=block
This allows the browser to detect a cross site reflection attack. If the browser sees a potential reflection attack, it will prevent the page from rendering in the browser. Instead, you will see something similar to this depending on the browser.

Remote LDAP Authentication Added to Numina Application Framework

A new feature has been added to the Numina Application Framework today which will allow users to authenticate against LDAP servers on remote networks. The new authentication type works through an intermediary service installed on the remote network. See the network diagram below which illustrates the points of connectivity. Connections at all points are encrypted.

The intermediary service can be located in the remote DMZ or the Internal network. The intermediary service must be authenticated to before any remote LDAP authentication requests can be made. It implements a similar Validation Ticket security that local Framework secured services would use.

Framework Offers OpenID Provider Support

OpenID LogoThe Numina Application Framework now allows users to login to 3rd party sites thanks to OpenID. To enable OpenID provider support go to Framework Administration > Settings > OpenID. The URL format is https://domain.com/id/DomainName/UserName. Once OpenID is enabled users can discover this URL under the My Account application. Version 1.0 and 2.0 of OpenID are both supported.

For more information on OpenID check out wikipedia and the official OpenID site.

OpenID SettingsOpenID Settings Page