Cenzic 232 Patent
Paid Advertising
sla.ckers.org is
ha.ckers sla.cking
Sla.ckers.org
Whether this is about ha.ckers.org, sla.ckers.org or some other project you are interested in or want to talk about, throw it in here to get feedback. 
Go to Topic: PreviousNext
Go to: Forum ListMessage ListNew TopicSearchLog In
IIS Secure Parameter Filter (SPF)
Posted by: Holyfield
Date: August 18, 2009 10:39AM

Hey Folks,

We have recently released a free IIS module written in C#, Secure Parameter Filter (or SPF for short), which aims to help protect web apps against parameter manipulation attacks. In doing so, the module also helps to prevent CSRF and reflected XSS by including an encrypted token with each request.

SPF has been a project of ours for the last year, and just last week, we open sourced SPF under the GNU Public License. Due to the important role sla.ckers.org community members have played in the success of other projects (such as the PHP-IDS project), we realize there is an incredible value to be gained for SPF as an open source security tool. We support open evaluations and smoketests of such security projects, and are looking forward to hearing community input on ways to improve SPF.

SPF can be downloaded from https://spf.codeplex.com/, and we have provided two live smoketest sample applications (the MSDN StockTrader application) at the following URLs. Remote detailed errors have been turned on to allow for easier debugging :-)

* http://trade-no-spf.gdsdemo.com/ (SPF not enabled)
* http://trade-spf.gdsdemo.com/ (SPF enabled)

Regards,

Brian H.
Gotham Digital Science



Edited 2 time(s). Last edit at 08/18/2009 10:41AM by Holyfield.

Options: ReplyQuote
Re: IIS Secure Parameter Filter (SPF)
Posted by: rsnake
Date: August 24, 2009 12:21PM

Man that was a confusing post to read! Hahah... You probably aren't aware of it, but SPF is already an acronym, and not just any acronym but a security one. :) It stands for Sender Policy Framework. It's an anti phishing/mail spoofing technology for DNS. Anyway, now that read it twice and figured out that SPF is not SPF, looks cool. Don't have time to test it, probably this whole week, but it looks like a fun thing to try out.

- RSnake
Gotta love it. http://ha.ckers.org

Options: ReplyQuote
Re: IIS Secure Parameter Filter (SPF)
Posted by: Holyfield
Date: August 24, 2009 01:25PM

@rsnake - Great, let me know if you get a chance to play around with it. And sorry for the confusion, I knew that might be an issue when I named it but liked the name anyways so I stuck with it :-).

Options: ReplyQuote
Re: IIS Secure Parameter Filter (SPF)
Posted by: rvdh
Date: September 01, 2009 12:49AM

Heh. U might wanna turn this of. Often forgotten:


Source File:  c:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\db8b6cd0\a2efbb29\App_Web_szky26ex.14.cs    Line:  0

A potentially dangerous Request.Form value was detected from the client (CreditCard="//--> "> <XSS\x0\\">").

Just testin'

[HttpRequestValidationException (0x80004005): A potentially dangerous Request.Form value was detected from the client (CreditCard="//--> "> <XSS\x0\\">").]
   System.Web.HttpRequest.ValidateString(String s, String valueName, String collectionName) +8721914
   System.Web.HttpRequest.ValidateNameValueCollection(NameValueCollection nvc, String collectionName) +111
   System.Web.HttpRequest.get_Form() +129
   System.Web.HttpRequest.get_HasForm() +8722023
   System.Web.UI.Page.GetCollectionBasedOnMethod(Boolean dontReturnNull) +97
   System.Web.UI.Page.DeterminePostBackMode() +63
   System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +6785
   System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +242
   System.Web.UI.Page.ProcessRequest() +80
   System.Web.UI.Page.ProcessRequestWithNoAssert(HttpContext context) +21
   System.Web.UI.Page.ProcessRequest(HttpContext context) +49
   ASP.account_aspx.ProcessRequest(HttpContext context) in c:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\db8b6cd0\a2efbb29\App_Web_szky26ex.14.cs:0
   System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +181
   System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +75


I'm not going through the code, but I wonder how the tokens are generated. based upon modification and different tokens on each URL it looks that they are generated based on predictable data? URL data?

Options: ReplyQuote
Re: IIS Secure Parameter Filter (SPF)
Posted by: rvdh
Date: September 01, 2009 12:54AM

Ah I see, you seem to generate the tokes based on this URL data:

symbols=s:0
symbols=s:1
symbols=s:2

Thus, that can be predicted and be prone to CSRF.

Options: ReplyQuote
Re: IIS Secure Parameter Filter (SPF)
Posted by: rvdh
Date: September 01, 2009 01:21AM

Other than that, looks pretty cool so far.

Oh, sorry about sending 55MB of form data, I just had to try.

Options: ReplyQuote
Re: IIS Secure Parameter Filter (SPF)
Posted by: Holyfield
Date: September 28, 2009 11:44AM

@rvdh - Thanks for testing...and sorry for the slow response (I guess I'm not getting email updates on this thread).

As for the HttpRequestValidationException, I've intentionally left detailed errors enabled so that it is clear what exceptions get thrown by the Framework versus SPF. I assume the detailed error message was what you were referring to (and not an exploitable XSS vector)?

Regarding the token, it is actually an HMAC of the URL, SessionID, SourceIP, and Timestamp of the request. The HMAC uses the private ASP.NET machine key so I don't think it is feasible for the token to be forged or predicted, but I would love to hear otherwise.

Hope this info helps. Thanks again.

Options: ReplyQuote
Re: IIS Secure Parameter Filter (SPF)
Posted by: Matt Presson
Date: September 28, 2009 12:22PM

SourceIP may pose some hurdles for you. Some ISPs have a bank of servers that all users come through, so this value is not always reliable as a unique identifier. Further, if the ISP does have a bank of servers there is no guarantee that the user will go through the same proxy server twice.


-Matt

Options: ReplyQuote
Re: IIS Secure Parameter Filter (SPF)
Posted by: Holyfield
Date: September 28, 2009 12:29PM

@Matt -- Agreed. This is an optional configuration flag that can be set in web.config. I have also thought about loosening it to the first 3 octets of the Source IP only.

Options: ReplyQuote
Re: IIS Secure Parameter Filter (SPF)
Posted by: Gareth Heyes
Date: September 28, 2009 01:31PM

@Holyfield

What advantage do you gain from including any part of the ip in the token anyway? Any XSS or CSRF attack would come from the client in question so including the IP seems pointless to me.

Also as Ronald mentioned your data for setting the hash is based on predictable data, if the machine key is static then you could possibly bruteforce it depending on the length and the method used to create the machine key

------------------------------------------------------------------------------------------------------------
"People who say it cannot be done should not interrupt those who are doing it.";
labs : [www.businessinfo.co.uk]
blog : [www.thespanner.co.uk]
Hackvertor : [hackvertor.co.uk]

Options: ReplyQuote
Re: IIS Secure Parameter Filter (SPF)
Posted by: Holyfield
Date: September 28, 2009 04:02PM

@Gareth: Including the source IP is only meant to prevent the token from being replayed from another machine (in the event that the token or SessionID are stolen or somehow brute-forced). This has no effect on preventing forged requests if there is a persistent XSS vulnerability in the target application. Persistent XSS is not an issue that SPF attempts to protect against by default.

Regarding the HMAC, this is an interesting thread I would like to continue. The Key used for the HMAC is “derived from” the machine key (it’s not actually the machine key). The key is derived by taking a static string (constant), which is then encrypted with the real machine key, which is then hashed, which is then encrypted again with the machine key, which is then hashed again. The first 128 bytes of that value are used as the HMAC key.

That "random" key value is then used as the secret key input to the HMAC generator. So that being said, I think there is still a concern that the HMAC is being generated based on "known" data (and the secret key). My understanding from you and @RVDH is that you both suggest an implied feasible brute force attack against the key because of this. I understand that a brute force attack is always "possible", but shouldn't this be computationally infeasible?

Let’s assume here that the underlying cryptographic algorithms being used are not broken (we have yet to talk about which algorithms are actually used….assume we are talking about SHA-512 HMAC, which is what the next release of SPF will be using). So the real question is...if using a “cryptographically sound” algorithm, is it worth including some “secret” data when generating an HMAC other than the private key or is that overkill?

Options: ReplyQuote
Re: IIS Secure Parameter Filter (SPF)
Posted by: rvdh
Date: September 28, 2009 08:01PM

Ok, you made me raise my eyebrows right there. especially on the hash->encrypt,hash->encrypt, which probably makes it even weaker then it already was. Look, I'm not pretending I know everything about cryptography, -far from it- but from what I know is that you walk on thin ice with your current implementation.

Yes HMAC suffers (like every crypto-algorithm that uses a key) from brute-force attacks. But the difference is, that if you have predictable data, it will be faster to brute-force. Since you seem to juggle keys around in a hashing algorithm, the key -or parts of it- are then used to generate a token with predictable data, logically, you can reverse that process in HMAC by trying to brute force the original key faster, due to predictable data. I see no valid reason why you should concatenate the data points you supplied, instead why not simply generate random data internally? It would solve it.

Ok, I'm not sure if this code is proprietary, but I reversed the .dll to have a peek if you don't mind ;-)


IIS.SPF -> CryptoEngine


   public static string GenerateHmacKey()
    {
        return FormsAuthentication.HashPasswordForStoringInConfigFile(CryptoProvider.Encrypt(FormsAuthentication
.HashPasswordForStoringInConfigFile(CryptoProvider.Encrypt(Constants.STR_HMAC_KEY, CookieProtection.Encryption), Constants.STR_SHA1), 
CookieProtection.Encryption), Constants.STR_SHA1).Substring(4);
    }

Ok, maybe you can enlighten me why you only get 4 chars right there?


public static byte[] GenerateIV()
    {
        RNGCryptoServiceProvider provider = new RNGCryptoServiceProvider();
        byte[] data = new byte[8];
        provider.GetBytes(data);
        return data;
    }

You might want to set the RNGCryptoServiceProvider to private, including private byte[], depending how it's scattered over classes of course, but it's a lot safer, now (byte[]) is stored on the high frequency heap, ok nitpicking, but who knows who can access the heap, right?

While using this, you could as well generate bytes to seed more randomness, instead of concatenating possible predictable data., because in the end it might be the very weakness while you use the correct PRNG in the first place.



  public static string GenerateToken(string strData, bool isCookie)
    {
        string str;
        int cookieTokenTimeOut;
        if (isCookie)
        {
            cookieTokenTimeOut = Options.Get().CookieTokenTimeOut;
        }
        else
        {
            cookieTokenTimeOut = Options.Get().TokenTimeOut;
        }
        if (cookieTokenTimeOut > 0)
        {
            str = CoreModule.intCurrentTimeStamp.ToString();
        }
        else
        {
            str = Constants.STR_ZERO;
        }
        strData = strData + str;
        if ((bool) ((Hashtable) AppDomain.CurrentDomain.GetData(DomainDataLoader.CONST_GLOBAL_CRYPTO_RULES))[DomainDataLoader.CONST_TIE_IP_ADDR])
        {
            strData = strData + HttpContext.Current.Request.ServerVariables[Constants.STR_SERVER_VAR_REMOTE_ADDR];
        }
        if ((bool) ((Hashtable) AppDomain.CurrentDomain.GetData(DomainDataLoader.CONST_GLOBAL_CRYPTO_RULES))[DomainDataLoader.CONST_TIE_SESSION_ID])
        {
            strData = strData + HttpContext.Current.Items[Constants.STR_SOURCE_ID_TOKEN];
        }
        return (str + Constants.STR_TOKEN_DELIMITER + GenerateHmac(strData));
    }

Here you seem to concatenate the predictable data and then generate a HMAC, problem is, what if I generate a subsequent request in the same context, but leave parts you concatenate blank? is this checked somewhere? it would generate a valid HMAC as well? since it would concatenate an empty string for example.


IIS.SPF -> Patterns

Here are the patterns btw, didn't look at them, but might be interesting to analyze/peer review them.

   static Patterns()
    {
        StrJavaScriptUrlPropertyRegex = "((location.href|window.location)\\s*?=\\s*?('|\")(.[^(\\'|\\\")].*?)('|\"))";
        StrHtmlUrlRegex = @"<(a|link|script).[^>]*?(href|src)\s*?=(.[^>]*)>";
        StrValueRegex = @"<(input|option).[^>]*?value\s*?=(.[^>]*)>";
        StrInputRegex = @"<(input|textarea).[^>]*?name\s*?=(.[^>]*)>";
        StrFunctionCallRegex = "(" + Constants.STR_FUNCTION_NAME_PLACEHOLDER + @")\((.+?)\)";
        StrFunctionArgsRegex = @"'[^\'\\]*(?:\\.[^\'\\]*)*',?|[^,]+,?|,";
        StrFormActionRegex = @"<(form).[^>]*?(action)\s*?=(.[^>]*)>";
        StrRewriteMapRegex = @"\${(\w+):\$(\d+)}";
        StrInputNameRegex = @"<(input|option).[^>]*?(name)\s*?=(.[^>]*)>";
        StrExcludedFormElementsRegex = "(TYPE\\s*?=\\s*?(\"|'|)\\s*?(image|text|submit|reset|password|checkbox)|<textarea)";
        StrFormRegex = "<form.+?</form>";
        StrSelectRegex = @"<select.[^>]*?name\s*?=(.[^>]*)>.+?</select>";
        StrLinkToSelfRegex = "HTTP" + 
(HttpContext.Current.Request.ServerVariables["HTTPS"].Equals("ON",
 StringComparison.InvariantCultureIgnoreCase) ? "S" : "") + "://" + ((HttpContext.Current.Request.ServerVariables["SERVER_NAME"] != null) ?
 HttpContext.Current.Request.ServerVariables["SERVER_NAME"].Replace(".", @"\.") :
 HttpContext.Current.Request.ServerVariables["LOCAL_ADDR"].Replace(".", @"\.")) +
 "(:" + HttpContext.Current.Request.ServerVariables["SERVER_PORT"] + ")?/";
        StrSlashDotSlash = @"(/\.)+/";
        StrSequentialSlashes = "//+";
    }
}

Options: ReplyQuote
Re: IIS Secure Parameter Filter (SPF)
Posted by: Gareth Heyes
Date: September 29, 2009 08:18AM

@Holyfield

What happens on a shared system? What if two virtual hosts have the same machine key? What's the length of the static constant? Will it always be different on new installations? How is it created?

------------------------------------------------------------------------------------------------------------
"People who say it cannot be done should not interrupt those who are doing it.";
labs : [www.businessinfo.co.uk]
blog : [www.thespanner.co.uk]
Hackvertor : [hackvertor.co.uk]

Options: ReplyQuote
Re: IIS Secure Parameter Filter (SPF)
Posted by: Holyfield
Date: September 30, 2009 02:26PM

First, let me start by re-iterating that all feedback received thus far is greatly appreciated – this is an excellent thread. In order to continue the conversation, I think we need to also clarify a few operational constraints that SPF is bound to:

NOTE: These operational constraints are partly due to the ASP.NET HttpModule architecture and partly for purposes of SPF usability. I am happy to discuss these requirements further as well.

1. By default, SPF uses the ASP.NET Machine Key to derive all keys it uses. The main reason for using the ASP.NET Machine Key is to alleviate the need for the developer/admin to generate a key and store it somewhere (like the web.config).

Also note that this is a unique key generated for the application (either automatically by ASP.NET or manually specified by the admin for shared web farm scenarios). This is NOT the Windows machine key that is used by the OS, rather it’s an application-specific key generated by ASP.NET.

2. SPF does not have a persistent data store other than the configuration settings within web.config. With the exception of its log file, SPF cannot write to the file system and does not have a database to store data. The only data store available to SPF is memory, and for that it uses the AppDomain context.

3. The mechanism used by SPF to generate its key needs to generate the same key every time given that the machine key has not changed. The primary driver behind this requirement is directly related to the fact that SPF does not have a persistent data store outside of the configuration file. For example, if SPF generates a truly “random” key at runtime, then SPF will generate a different key every time the application pool recycles or otherwise stops/starts (which is much more frequent than you probably realize). This inherently would invalidate all previously issued tokens , so it’s not really feasible.

Now that those requirements are hopefully clear, let’s talk through some of the comments.

RVDH Said: “Ok, you made me raise my eyebrows right there. especially on the hash->encrypt,hash->encrypt, which probably makes it even weaker then it already was. Look, I'm not pretending I know everything about cryptography, -far from it- but from what I know is that you walk on thin ice with your current implementation. “

@RVDH: The intention is for SPF to have its own key and not directly use the ASP.NET machine key for the HMAC. However, since the ASP.NET key is the only configurable key available (SPF does not manage its own keys in a configuration file) this key is used to derive the SPF key. The encrypt -> hash -> encrypt -> hash logic is intended to generate a unique key for SPF in a repeatable manner. I am open to suggestions on how this can be strengthened, but keep in mind generating something “random” at runtime won’t work since this process needs to be repeatable.

RVDH Said: “Yes HMAC suffers (like every crypto-algorithm that uses a key) from brute-force attacks. But the difference is, that if you have predictable data, it will be faster to brute-force.” Since you seem to juggle keys around in a hashing algorithm, the key -or parts of it- are then used to generate a token with predictable data, logically, you can reverse that process in HMAC by trying to brute force the original key faster, due to predictable data. I see no valid reason why you should concatenate the data points you supplied, instead why not simply generate random data internally? It would solve it."

@RVDH: Agreed, however I am still not clear as to the computational feasibility of this attack. It seems like the suggestion here is to essentially “salt” the HMAC similar to how password hashes should be salted to thwart cracking attacks. While I see how this would make the brute force attack more difficult, is this really necessary when using HMAC? None of the cryptography guidance I have seen suggests that the HMAC requires salting. Additionally, doing this would pose a challenge since SPF does not have a persistent data store, which it would need to later validate the “salted” HMAC.

RVDH Said: "Ok, I'm not sure if this code is proprietary, but I reversed the .dll to have a peek if you don't mind ;-)"

@RVDH: No problem at all –SPF is open source. I would suggest you download the source code from CodePlex at http://spf.codeplex.com/.

RVDH Said: “Ok, maybe you can enlighten me why you only get 4 chars right there?”

@RVDH: There are actually 36 characters returned there, not 4. The String.Substring(int32) method returns a substring starting at the specified character position. So in this case, the original string (generated by the hash function) is 40 characters long. Ironically the original intention was to return 32 characters in order to derive a 128-bit key (so it should have been 8). As it turns out, the ASP.NET HMAC functions accept a variable key length so this truncation is not even necessary.

RVDH Said: “You might want to set the RNGCryptoServiceProvider to private, including private byte[], depending how it's scattered over classes of course, but it's a lot safer, now (byte[]) is stored on the high frequency heap, ok nitpicking, but who knows who can access the heap, right?”

@RVDH: Good point, I will look into this and make private if feasible.

RVDH Said: “Here you seem to concatenate the predictable data and then generate a HMAC, problem is, what if I generate a subsequent request in the same context, but leave parts you concatenate blank? is this checked somewhere? it would generate a valid HMAC as well? since it would concatenate an empty string for example.“

@RVDH: The ability to tie tokens to the SessionID (SourceID Token) and Source IP address are optional. By default this is enabled, and if used these should never end up null since:

- If a request with a null Source ID token is received, a new SourceID value is generated at the beginning of SPF’s request processing (if this is not the case, let me know as this would likely be a bug)

- The source IP address is populated by IIS and is never null in any case that I am aware of. Again, let me know if this is not the case.

RVDH Said: “Here are the patterns btw, didn't look at them, but might be interesting to analyze/peer review them.“

@RVDH: Please do - peer review is always welcome and encouraged. SPF is open source…you can download the code from CodePlex for a more complete view of how it works (http://spf.codeplex.com/). It should be noted that most of those patterns are left over from when SPF previously was parsing HTML responses using Regular Expressions. Now that HTML Agility pack is used, they are not used and will likely be removed in the next release.

Gareth Said: "What happens on a shared system? What if two virtual hosts have the same machine key?"

@Gareth: The ASP.NET machine key should be unique for each application. This is managed automatically by IIS or manually overridden by the admin/dev in the web.config. Managing this key value is outside the scope of SPF. Let me know if you think this presents a concern.

Gareth Said: “What's the length of the static constant? Will it always be different on new installations? How is it created?”

@Gareth: No, it is static. As mentioned to RVDH, there needs to be a repeatable way for SPF to derive its keys from the ASP.NET machine key. Let me know if you have any ideas on how to strengthen the key derivation process as this is something that needs to be done properly (within the realm of feasibility). Keep in mind SPF doesn’t have a persistent data store other than the web.config, which is not writeable at runtime.

Options: ReplyQuote
Re: IIS Secure Parameter Filter (SPF)
Posted by: Gareth Heyes
Date: October 01, 2009 10:17AM

@Holyfield

Thanks! I think IMO the attack wouldn't be realistic. However this may be:-

Here is an attack scenario. I post to a forum with a link to an external web site. The web page reads the referrer information and creates a iframe page to the original page, using the token from the referrer the pages displays correctly. The attack fools the user into clicking a link within the iframe (aka crapjacking, I mean clickjacking), the user then performs CSRF or XSS on themselves.

I tried to reuse the same token and was successful on the demo:-
http://trade-spf.gdsdemo.com/Quotes.aspx?symbols=s:0&UrlToken=0:54146B85AEECF98A5FDAE1A7915F56A78E858497

So here if I could post links then the user could be tricked into buying stock

------------------------------------------------------------------------------------------------------------
"People who say it cannot be done should not interrupt those who are doing it.";
labs : [www.businessinfo.co.uk]
blog : [www.thespanner.co.uk]
Hackvertor : [hackvertor.co.uk]

Options: ReplyQuote
Re: IIS Secure Parameter Filter (SPF)
Posted by: Holyfield
Date: October 01, 2009 12:03PM

@Gareth: Yes, that attack sounds like it would work. The attacker would probably need to also create the links that they want to exploit with the click-jack too since it's not likely that by default the same forum page would have a one-click link to buying specific stocks. But provided that they had the ability to create a link on that page to their own site in the first place then this would likely be doable.

I think preventing this attack would require one-time links as opposed to links that expire after a certain time (which is what SPF currently does). This behavior maps back to the fact that SPF doesn’t have a data store to record which tokens have been used already (or which ones haven't). It would be nice to come up with a workable solution for this.

The scenario of allowing arbitrary user-defined links also breaks the ability for SPF to protect against URL parameter manipulation, since the user is able to craft their own links with arbitrary page/parameter combinations. These links would then get tokenized when rendered by SPF and thus become useable. I'm not sure of a way to protect against this scenario since SPF would need to know whether a given link was created by the site admin or by the user (similar to why SPF can't protect against persistent XSS).

That being said, these are two scenarios that I would like to eliminate if possible. Any thoughts? I'll keep thinking about this and see what I can come up with too.

Options: ReplyQuote
Re: IIS Secure Parameter Filter (SPF)
Posted by: rvdh
Date: October 01, 2009 02:43PM

Source was not available: http://spf.codeplex.com/SourceControl/ListDownloadableCommits.aspx

still isn't right? or is it someplace else?

Options: ReplyQuote
Re: IIS Secure Parameter Filter (SPF)
Posted by: rvdh
Date: October 01, 2009 02:53PM

@Gareth, Holyfield

Cryptographic attacks might be feasible, but there is no way for testing this other than pointing out possible weaknesses. It needs review by someone who is cryptographically savvy, and that isn't me. ;-) It might suffice for a simple website, but once banks are going to implement this, you might have a problem.

As I said, I do not see the point in gathering entropy from the client, because:

a. could be predicted.
b. could be modified on subsequent request.
c. entropy is simply too weak to be cryptographically secure for unique tokens.

So, why not just grab the same PRNG and create entropy server-side? next to that, you could still save the other "entropy" inside a session for whatever reason that was good for. It would break nothing. But I really do not recommend to generate tokens based upon the client's entropy, it's bound to be fail somewhere. I did that too in many application, and learned it the hard way.

Options: ReplyQuote
Re: IIS Secure Parameter Filter (SPF)
Posted by: Holyfield
Date: October 01, 2009 05:44PM

@rvdh: Sorry, perhaps I should have specified that there are two releases (one Binary and one Source). Here's a direct link to the current source release: http://spf.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=31688

Regarding additional entropy within the HMAC, SPF does not attempt to generate entropy from the client. SPF is using the HMAC merely to verify that the data sent to the client has not been tampered with. As I mentioned before, there is no way for SPF to store any unique entropy on a per-request or per-session basis since SPF doesn't store data within the session (it uses a session id, but not for session-based storage). Storing session data on the server would also break any sort of web farm scenario, which would be problematic.

There are two solutions, however, that I think could address your concern and would not require persistent storage:

1. Derive another "unknown" value using the ASP.NET machine key (when the module starts up and in a repeatable manner) and pre-pend that value to the other request elements when calculating every HMAC. This way SPF will be able to reliably re-calculate the HMAC on every request without the user knowing ALL of the elements needed to calculate the HMAC. This secret value would be unique as it is based on the ASP.NET machine key.

2. Encrypt the values taken from the client (URI, QueryString, SessionID, Source IP) with a 2nd key (also derived from the ASP.NET machine key) and use the cipher-text output to generate the HMAC. This could easily be recalculated on the way back on, however I think there would be a significant performance hit since there would be an additional crypto operation every time we generate an HMAC (which is pretty often). Something tells me this solution would not be useable due to the performance impact.

I'll need to think more about option 1 above, but I think it would somewhat address the concern you are raising and provide minimal additional overhead.

Options: ReplyQuote


Sorry, only registered users may post in this forum.