What is the best and most simple way to secure Web API call? For example if we have client who is sending a username and password for authentication. If we send it like a plain text we are leaving doors open for hackers. Can someone maybe share tutorials about implementing HTTPS for this kind of scenario. I believe that for start making a call over HTTPS would be enough.
Take a look at this tutorial for IIS: http://www.iis.net/learn/manage/configuring-security/how-to-set-up-ssl-on-iis.
Also see this: http://www.asp.net/web-api/overview/security/working-with-ssl-in-web-api
Related
I'm developing both server and client side of a web application and it is almost finish. Now, it is time to secure it.
I read lots of articles and Q-A sites to understand the principles of the concept. But there are still question marks on my mind.
There is a similar question here:
How do I secure REST API calls?
They suggested to use token-based security system, which is very common and practical way. Also services like Firebase, Auth0 are providing this security system.
And this is about "how and where to store token": https://auth0.com/docs/security/store-tokens
If so, how can token protect server from fake-calls while we are storing it in the browsers local storage?
Explaining it with an example in order to be clear:
My client-side code has a form with options. One of the option can be selected via drop down option and there are only "1,2,3,4" in those options. So that, client can never send a form with "5" value to the server. But what if someone use a API tool (for example postman) to send a form with a value of 5? Attacker still can add a token to that request. First login to system as normal user. Than open the developer console of the browser, copy your token and paste to the header of your fake-request.
Not allowing the cross origin calls may solve the problem. But I am not sure if this means server and client should run on the same domain (or host)?
Bonus from stackoverflow: Stackoverflow's use of localstorage for Authorization seems unsafe. Is this correct else how do we strengthen it?
They are also discussing the similar question from another aspect. (Not for the server security but for the user's security.)
Not related but in case of need: front-end is developed with Angular 5, server is developed with Java and Spring Framework.
I'm developing a web application using Java EE and some open source components (Spring, Struts 2, jQuery, and so on). Some of my web pages require authentication (Spring Security) and other not. I write some REST APIs (Restlet) and I use them from my pages by AJAX calls (jQuery). I know that other web sites can not use my REST APIs unless I enable CORS and this is what I want.
However any non-browser client (curl, Java applications, and so on) can call my REST APIs: how can I forbid this? I can not use authentication for all REST APIs because I use some of them in web pages that should not require authentication. I know that some APIs (like Facebook SDK) require an application-id in order to enable calls, but anyone can steal the key from the Javascript code included in my web pages.
I would like to recognize from the server side if an HTTP request has been sent from a browser or other client applications in order to apply some kind of authentication only in the second case. As I concern, any client application can set any HTTP header, so I can not HTTP headers, can I? I think that my problem should be a common problem, so maybe I miss something.
There's nothing you can do.
Most folks are worried about unauthorized users using their applications. You're worried about unauthorized programs.
Yet everything that a program needs to communicate with your server, it will be told (by the server as in a token, or by the user as in a credential).
Why are you afraid of "non-browser" clients? Why do you care what client they use? How is a non-browser client different than a normal browser for your use cases?
Answer that question, and you'll find better answers.
Are you afraid they'll "screen scrape" your site, quickly download it with something like wget? Then you can put in some server side rule gating their access (if IP x.y.z.w makes more than Q requests per BLEEM of time, then discard request/sleep 10s/send content REALLY slowly).
Those kinds of measures are what you have to do. You can't "secure" the client, it's not your client to secure. You have to secure your server, and address the concerns head on.
Remember rule #1 of client/server design: "Never trust the client". On the internet, no one knows you're a bot.
I want to write a http server with node.js that supports NTLMv2 authentication.
Evertything works fine with the handshak (type1, type2, type3 messages) and I get my type3-message from the client (Chrome Browser). In this message that is being sent to the server there is a ntlmv2 response that I can read within my node.js server. How I can authenticate if this reponse is valid?
According to [1] I have understood the type3 message and I was able to create my own node.js-routine to generate these hashes. So when I have the password I can create a hash that is equal to the one I get from the browser. But how can I authenticate this hash/response without knowing the password? How can I authenticate this against a DomainController/ActiveDirectory in my network?
If you have look at [2], there is a picture that describes my question perfectly. How can I execute the steps "4" and "5" of this picture?
Thanks,
Laryllan
[1] http://davenport.sourceforge.net/ntlm.html#theType3Message
[2] http://msdn.microsoft.com/en-us/library/cc239685.aspx
A quick web search affirms that everyone seems to get stuck at about the same point.
The best response to this topic I've seen so far is here:
Windows Authentication Headers without .NET. Possible?
To valid NTLMv2 credentials you would need to perform SecureChannel encrypted RPCs with the NETLOGON service of an Active Directory domain controller. Which is to say, this is a difficult thing to do. If your server supports Java Servlet Filters there's Jespa.
Otherwise, there are modules that can do the auth at the webserver level like an Apache module or by turning on IWA in IIS. But of course these type of solutions are somewhat limited in a number of ways.
Long story short, i have a couple of clients who wanted to manage some stuff on their website, all websites are build with nodejs.
I'v built a small CMS for those websites.
Keep in mind that none of my websites https,
here is what i want to happen:
a client goes to my website and submits a form with his password and username
i http POST his credentials to his website
his website returns a json with OK 200 if the credentials are ok
questions:
Is this the best way to do it ?
what encryption method should i use?
No this is not the best way to do it.
You should never authenticate through http, and you should definitely not do you own encryption between the server and the clients. Please consider using SSL.
You can get a wildcard SSL certificate which supports subdomains and thus multiple websites, like:
x.example.com
y.example.com
z.example.com
This is a recurring question, and the answer will always be to use established technologies and algorithms, instead of reinventing the wheel and possibly introducing security holes of your own.
Please see this article on javascript cryptography and why not to do it.
But when you have the website wrapped in SSL you can use the approach you explained and it will then be secure.
greetings,
i have a simple question.
I have some page that i use for SAML Authority certificate.:
http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue
the coleague of mine asked me why is this "dead link". Well, I told him that it is a soap protocol and it is not a good idea to communicate with the front end user using web browser. But why the link is actually inaccessible from the browser?
Namespaces look like URIs for the sake of handling ownership to ensure uniqueness, but they aren't actually URIs.