excuse me if i will sound little stupid but this thing had confused me to the core and i have been searching like crazy on net with no ultimate answer so i hope some one would shed more light on this matter.
now i wanna create a portal site and my client require that everything should be AJAX'ed so i have been playing with ASP.NET AJAX 4 and client site templating and web service, and of course the performance is great with JASON results, but my web Service code will be Public because anything available to JAVA script is available to anyone so as i read to avoid this i must :
use SSL but this is a portal site and front end should not use SSL
Authentication, will this is fine but for back-end and not front-end as login is not required.
after reading a lot as i have mentioned, i have come to the following pitfalls when using web service with AJAX and hope there is a solution or at least a way to bring more security
DOS:
i have read some articles that suggest you should throttle using IP detection and block this request for a while but here are some of the things i am worried about
will it affect search engine crawlers ?
will the hacker be able to bypass this by using proxy or other mean ?
Session HighJacking:
this is scary i still don't know how this can happen when you are using ASP.NET membership, i thought it is a pretty solid membership system!
and will a hacker be able to steal someones pass through this method?
a way to hide your code or encrypt it:
i think i am making a fool of myself here because i have mentioned that if it is public to java script then it is public to anyone, but my client would not want people to see the code writing logic and function.
Hide Webserivce:
like if you use fiddler you can see in the RAW data the path to for example www.mysite.com/toparticles/getTopArticles(10) again this scares my client and i have tried to disable WSDL and documentation in webconfig but this only blocks direct access to the file and nothing more or am i wrong! is there a way to hide the path to web service?
so all in all my top concerns is to prevent hammering any of my web services and hide my code as much as possible.
so am i to paranoid as on the front end i am going mostly to be pulling Data but again i may give user the option to save for example his widget preferences in DB, etc... and it is not gonna be through SSL thus the above security threats are valid.
i hope some one can also share his experience on this matter,
thanks in advance.
Any functionality exposed on the web is going to be, well... exposed on the web. Even if you were using pure ASP.NET with postbacks, sniffers can see the traffic and mimic the postbacks, Ajax just takes that to its logical extreme. Webservices are (for the most part) just like any other get/post system (RESTful or not).
There are some methods that you can use to secure your webservices from unauthorized access, but in truth these are the exact same things you would do to secure any other site (asp.net, traditional web, etc).
There are lots of articles all over the web about how to secure your website, and these will apply equally well to AJAX, Webservices, etc.
If you are really concerned about your webservices being publicly exposed, you can use your own custom reverse proxy to hide the services inside the customers network and only expose the proxy to the outside world. You can then secure the services so they are only accessed through the proxy and provide whatever appropriate security on the proxy you feel relevant. In this way all traffic comes through servers that you specify and is restricted (to a reasonable degree) from prying eyes. In general though I think this might be over-kill especially for a portal site.
One thing to talk with your client about is the upsell value of using webservices as a sellable product to integrators. In other words, designing the security into the webservices and using the portal only as an example of how to put it all together. A clear example of this is SharePoint, which is in truth a collection of webservices and processes and the website is really just for convenience, the power of SharePoint is in the interop of the services.
For more specific answers to your security questions, there are plenty of posts here on SO as well as the web covering each of your specific points.
Related
Sorry no code here because I am looking for a better idea or if I am on the right track?
I have two websites, lets call them A and B.
A is a website exposed to the internet and only users with valid account can access.
B is a internal (intranet) website with (Windows authentication using Active directory). I want Application B (intranet) to create users for Application A.
Application A is using the inbuilt ASP.NET JWT token authentication.
My idea is to expose a Api on the extranet website (A) and let (B) access this API. I can use CORS to make sure only (B) has access to the end point but I am not sure if this is a good enough protection? We will perform security penetrations test from a third party company so this might fail the security test?
Or
I can use entity framework to a update the AspnetUsers table manually. Not idea if this is feasible or the right way or doing things.
Any other solution?
In my opinion, don't expose your internal obligations with external solutions like implementing APIs etc ...
Just share the database to be accessible for B. In this way, the server administration is the only security concern and nobody knows how you work. In addition, It's not important how you implement the user authentication for each one (whether Windows Authentication or JWT) and has an independent infrastructure.
They are multiple solution to this one problem. It then end it really depends on your specific criteria.
You could go with:
B (intranet) website, reaching into the database and creating user as needed.
A (internet) website, having an API exposing the necessary endpoint to create user.
A (internet) website, having data migration running every now and then to insert users.
But they all comes with there ups and downs, I'll try to break them down for you.
API solution
Ups:
Single responsibility, you have only one piece of code touching this database which makes it easier to mitigate side effect
it is "future proof" you could easily have more services using this api.
Downs:
Attack surface increased, the API is on a public so subject to 3rd parties trying to play with it.
Maintain API as the database model changes (one more piece to maintain)
Not the fastest solution to implement.
Database direct access
Ups:
Attack surface minimal.
Very quick to develop
Downs:
Database model has to be maintained twice
migration + deployment have to be coordinated, hard to maintain.
Make the system more error prone.
Migration on release
Ups:
Cheapest to develop
Highest performance on inserts
Downs:
Not flexible
Very slow for user
Many deployment
Manual work (will be costly over time)
In my opinion I suggest you go for the API, secure the API access with OAuth mechanism. It OAuth is too time consuming to put in place. Maybe you can try some easier Auth protocols.
I have a scenario where I have multiple websites using a commnon dll for authentication and general user detail fetching.
I now need to update the common dll with a slightly different login logic and it means I'll need to push this new dll into every website and do a release process for each.
I'm wondering whether it's better to host the common authentication methods in a webservice of some sort then have the websites call that internally. Would it be an internal web service? ajax callbacks from an server side only website? Or stick with the dll method to ensure code changes doesn't break the sites?
Are there any security concerns when not using a dll for this kind of task?
Using a webservice seems a good way to do that. I will cause less memory usage and can be updated independantly from the wesites (if ever needed).
You could go for a WCF services (with dual tcp?) maybe.
Both approaches work in my opinion, but there are significant differences between them that we should keep in mind.
First of all, all of this depends also on the language you are using, because sometimes the best theoretical answer is not always easily implemented in each and every language, making it practical unusable.
So, with this in mind, the best way for me is to have an internal web service, who deals with all requests regarding this "authentication and general user detail module", assuming that all websites use the same DB (or data layer) (otherwise, you will need to create a web service for each one and it's another completely different story). This approach will give you flexibility and maintainability. You could use direct ajax requests to this web service, or make the calls from you website server, and them reply to the browser already with that information. (this second option is more time consuming but much more secure, and if it is a real internal web service (ie hosted on the same machine, the lag will not be noticeable)).
The dll approach should if you need to apply the same business logic to different services. In practical terms: you have two completely separated web sites, that use the same kind of authentication logic. Keep in mind that using this approach to websites that use the same data layer, will force you most of the times to have "deprecated ways" working together with the new implementations, while you are updating the dll on all websites.
Regards,
Like a lot of people I've gone with ASP.Net Forms authentication because it's already written and writing our own security code we're told is generally a bad idea.
With the current problems with ASP.Net I'm thinking it might be a good time to look at alternatives.
Important: ASP.NET Security Vulnerability - ScottGu
Video demonstrating attack
Microsoft advisory including workaround
From what I understand Microsoft tend to store things on the client side because it makes it easier to operate over server farms without needing database access calls.
I don't really care about server farms though and I'd like to simply have an opaque cookie that demonstrates my lack of trust in the callers.
Is there a decent solution that's already been proven solid?
Update: to clarify my question. I'm talking about the authentication token part of the forms authentication that I'd like to replace. The back end is quite easy to replace, you can implement the interfaces to store your users and roles quite easily. You can also use existing libraries like http://www.memberprotect.net/ which has been mentioned here.
I'd like to change the front end part of the process to use a token that doesn't provide the client with any leverage. Sticking with the existing back end infrastructure would be useful but not essential.
I've been working on an HttpModule that basically does what you're looking for. When a FormsAuthenticationCookie and FormsAuthenticatedTicket are generated, before the response is sent to the client (i.e., during the processing of the postback of the Login page/action), all of the details about the cookie & ticket are stored on the server. Also, the UserData from the ticket is moved to the server (if present) and replaced with a salted SHA-512 hash of the other properties in the ticket along with a GUID that serves as a key into the server-side store of the ticket.
The validation of the cookie & tickets compares everything the client provided (optionally including their IP address) with all of the properties that were known about them at the time they were issued. If anything doesn't match, they are removed from the request before the FormsAuthenticationModule even kicks in. If everything does match, the server's UserData is stuck back in the FormsAuthTicket in case you had any modules or code that depend on it. It's all transparent. Plus, it can detect suspicious and blatantly malicious requests and inserts a random delay in the processing. It also has some explicit padding oracle workarounds in there.
The demo app actually lets you create/modify your cookie & ticket values on the server, with the server encrypting your ticket for you with the machine keys. This way you can prove to yourself that you can't create a ticket/cookie that gets around the server validation unless you write the exact set of data to the server (which should be impossible under normal circumstances).
http://sws.codeplex.com/
http://www.sholo.net/post/2010/09/21/Padding-Oracle-vs-Forms-Authentication.aspx
http://www.sholo.net/post/2010/09/22/Sholo-Web-Security-and-the-EnhancedSecurityModule.aspx
-Scott
If you have your keys in the web.config and the attacker gets to it, they are pretty much done.
If that's not the case (they don't get the keys from your .config), then afaik the padding oracle shouldn't allow them to sign a new auth ticket. The paper explains ability to encrypt by taking advantage of the cbc mode, ending with a tiny bit of garbage there. It should be enough to make it an invalid signature.
As for the video where they get the keys with the tool, its against a dotnetnuke install. A default dotnetnuke has those keys in the web.config.
Implement the workaround, keep your keys off your site level web.config, if you don't use webresource.axd and scriptresource.axd disable those handlers, and apply the patch as soon as ms releases it.
I will simply recommend taking a look at InetSolution's MemberProtect product, it's a component designed with security in mind for the banking and financial services industries but is widely applicable to any site designed on ASP.NET or application built on top of the .NET platform. It provides support for encrypting of user information and a host of authentication methods from the simplistic to the very advanced and the various methods and functions are designed to be used as the developer sees fit, so it's not a canned solution so much as a very flexible one, this may or may not be a good thing depending on the particular situation. It's also a very solid foundation on which to build new member-based websites and applications in general.
You can find out more about it at http://www.memberprotect.net
I am the developer for MemberProtect and I work at InetSolution :)
This isn't a value-less question, but I have to say that I think your logic is suspect. It's no bad idea to consider alternative authentication solutions, but the newly-announced ASP.NET vulnerability should not push you to abandon a current (presumably working) solution. I'm also not entirely sure what the relevance of this comment is:
From what I understand Microsoft tend to store things on the client side because it makes it easier to operate over server farms without needing database access calls.
What is it about the vulnerability that makes you think that ASP.NET forms auth is broken any more than another solution?
The detail of the MS advisory would seem to suggest that pretty much any other authentication system could be rendered similarly vulnerable to attack. For example, any solution that uses the web.config file to store settings would still have its settings open to the world, assuming a successful attack.
The real solution here is not to change security, but to apply the published workaround to the problem. You might switch authentication providers only to find that you are still vulnerable, and your effort has gained nothing.
Regarding tokens/sessions: you have to push something to the client for authentication to work (whether you call it a token or not), and it's not this part of the process that causes the current security issue: it's the way the server responds to certain calls that makes this secret vulnerable to attack.
I was discussing load-balancing with a colleague at lunch. I admit that I know very little about this topic. We were discussing the various ways of maintaing session in a ASP.NET application -- none of which suited the high performance load balancing that he was looking for.
What about Silverlight? says I. As far as I know it is stateless, you've got the app running in the browser and you've got services on the server that feed/process data.
Does Silverlight totally negate the need for Session state management? Is it more friendly to load-balancing? Is it something in between?
I would say that Silverlight is likely to be a little more load-balancer friendly than ASP.NET. You have much more sophisticated mechanisms for maintaining state (such as isolated local storage), and pretty much, you only need to talk to the server when (a) you initially download the application, and then (b) when you make a web service call to retrieve or update data. It's analogous in this sense to an Ajax application written entirely in C#.
To put it another way, so long as either (a) your server-side persistence layer knows who your client is, or (b) you pass in all relevant data on each WCF call, it doesn't matter which web server instance the call goes to. You don't have to muck about with firewall-level persistence to make sure your HTTP call goes back to the right web server.
I'd say it depends on your application. If it's a banking application,then yes I want something timingout out after 5 minutes and asking for my password again. If it's facebook then not so much.
Silverlight depends on XMLHttpRequest like any other ajax impelementation and is therefore capable of maintaining a session, forms authentiction, roles, profiles etc etc.
The benefit you are getting is obviating virtually all of the traffic. json requests are negligable compared to serving pages. Even the .xap can be cached on the client.
I would say you are getting the best of both worlds in regards to your question.
My company is considering working with another company on a particular module. Information would be sent back and forth between us through my web service. Thing is, my web service uses ASP.NET, and they use classic ASP. Everything I've found online says (it's a pain, but) they can communicate, but I'm not clear on some details.
Specifically, do I have to enable GET and POST on my web service? If I don't have to, but could, would enabling them make the communication significantly easier/better? And finally, GET and POST are disabled by default because of security. What are the security risks involved in enabling them?
My first question should be "Why use Soap?". The simplest common demoninator that you have between the two is XML so thats a given. However the choice of transport can be as simple as an single .ashx or as clever as WCF service.
Since your first consumer is using ASP why use a technology that makes it difficult for them?
The true bottom line here is what are your security requirements?