May I ask someone who was responsible for security of websharper code, to have a look at on these issues:

Issue 1 – CSRF token is only sent in cookies and is not being validated

Issue 2 – .ASPXAUTH cookie tokens are not being invalidated at logout

By on 10/25/2017 2:17 AM ()

Issue 1 - this is for RPC calls, right? The CSRF token should definitely be present as a header as well, and the request rejected if it isn't there, as long as the server doesn't call Web.Remoting.DisableCsrfToken().

Issue 2 - Yes, this is indeed a potential problem. We use ASP.NET's cookie authentication module, but without a persistent storage that would be required to permanently invalidate cookies. That is something that we need to figure out a proper API to provide (we don't want to be opinionated in terms of things like what persistent storage you use).

By on 10/25/2017 2:52 AM ()

To issue 1, person making security certification says:

The image below show a state changing request that results in a cashout. The only mechanism to prevent CSRF present in the original request is a “csrftoken” cookie.

To test if this request is protected, we manually removed the “csrftoken” cookie before sending the request. Despite lacking the CSRF protection cookie, the request is processed successfully by the server, implying that the CSRF token is not being verified.

Even if the cookie value was not removed, sending the CSRF token in a cookie is not sufficient protection against CSRF attacks by itself, as cookies are sent in any request sent by the browser, even if they are not same origin.

Sending a X-CSRF-Token header with the request, with the same value as the cookie, and validating the received values on the server should be enough to prevent the attack. This protection should be included in all requests that change the application state.


I am not expert, so my question is what I can do, to make my websharper app secure.

Again I repeat what I asked Adam, in one of his videos he says that websharper web apps were delivered in bank sector as well, so I wonder how such web apps could go successfully through security certification?

By on 10/25/2017 3:12 AM ()

The token is included as a header in all RPC requests. I think that they didn't realize that there is a mechanism to automatically send it to the client. When the CSRF header is missing from an RPC request, the server's error response includes a Set-Cookie for the token and a body that identifies that the request was rejected due to the lack of token. Upon receiving this response, the client tries the request a second time. If this client is an accepted origin then this second request will succeed, and I suspect that this is what they mistook for a lack of checking.

If they try to make a request from an origin that is not accepted by the server, then they will see it properly rejected.

By on 10/25/2017 3:35 AM ()

Loïc, in WebSharper code you have got:

1
2
    | _ when Remoting.csrfProtect && not (explicitlyAcceptedOrigin.IsSome || checkCsrf()) ->
        Error (403, "Forbidden", "CSRF")

So when a request is made from the same origin, checkCsrf() is not executed, so they are correct that CSRF is not checked and you have got problem in your code.

Here they say:

https://stackoverflow.com/questions/5207160/what-is-a-csrf-token-what-is-its-importance-and-how-does-it-work

that Cross-Site Request Forgery is actually made by requesting from the same origin, read about trick how it is done.

So when Remoting.csrfProtect is true, what you set by default in code, you really should check CSRF, so:

1
2
| _ when Remoting.csrfProtect && not (checkCsrf()) ->
    Error (403, "Forbidden", "CSRF")

Please, explain that to me, as I am not expert in this area, or should I set something on my IIS to make this work?

By on 10/28/2017 4:28 AM ()

Thanks Loïc, but they still say there is security problem in the code:

We then used the Cash Out All interface, selected only this game, and clicked the “Cash Out All” button. We intercepted the original request sent by the application, which can be seen below. There are no CSRF token headers in the original request, but there is a csrftoken cookie.

To check if this cookie token is validated, we modified the request and manually removed the “csrftoken” cookie before sending it. The modified request can be seen below.

Despite lacking the CSRF protection cookie, the request is processed successfully by the server, as seen in the reply below. This implies that the CSRF token is not being verified.

Without any form of validation, the presence of the cookie is of no value. A stronger protection against CSRF would be sending a X-CSRF-Token header with the request, with the same value as the cookie that is set by the server, and validating the received values on the server. This protection should be included in all requests that change the application state.


Frankly to say I have no idea what are they talking about. Is there a way to send you doc, so you read and see attached pictures.

What tools such people use to check security issues, so I would be able to test it myself trying to hack my web app.

By on 10/27/2017 9:36 AM ()

I suppose you have to authenticate to these third party APIs, have you done that?

By on 10/5/2017 12:48 PM ()

Yes, Adam I did so, I am certified betfair software vendor from 2007. I will ask them again, why:

1
Set-Cookie: .ASPXAUTH=D475A57...C9EC; expires=Thu, 05-Oct-2017 16:50:48 GMT; path=/; HttpOnly

is a problem, it should be:

1
Set-Cookie: .ASPXAUTH=D475A57...C9EC; expires=Thu, 05-Oct-2017 16:50:48 GMT; path=/; secure; HttpOnly

The fact is that WebSharper does not set secure; when context.UserSession.LoginUser or whenever set cookies is fired, even when web server is set to:

1
<httpCookies domain="www.cashoutall.com" httpOnlyCookies="true" requireSSL="true" />

I know you use ASP.NET authorization, had no time to investigate it deeper, but the same:

1
context.UserSession.Logout()

works correctly.

My English is not so good, therefore I do not know if you understand what I want to say, similarly like when I asked for fixing my problem with redirection. I am not an expert in web development, but the way you implement redirection is totally wrong, mainly when I pointed to problems with Chrome and Mozilla browsers, the way those browsers treat such redirections, they save URLs in cache, so when you add "salt" to such URLs, imagine what you actually do, browser saves every such URL in cache.

By on 10/6/2017 12:50 AM ()
IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy
Built with WebSharper