I'm currently planning to develop a HTML5 app. The basic concept is the following:
A user should be able to create a profile with username and password. The Server should be implemented in Ruby on Rails providing a JSONP Api (for Cross-Domain issues).
So the App will send Ajax requests to the Server and get responses from it.
My idea was now to transmit a session_key (generated by server) on the first response back to the client. Then the client has to authenticate himself with this token.
But now i have some issues.
How can i secure the first call of the client (when he is transmitting user and password)?
How can i protect the Session-key from beeing spyed out?
I am a complety noob in security aspects. Therefore it would be great if i could get some hints where to look at.
Secure your connection with SSL. This should require no changes in your code apart from putting 's' after 'http' ;-).
I used add a checksum to the ajax parameters (calculated using the submitted data), and then to crypt the hole ajax request into one string.
Somthing like sRequest=459fdjnfdw4r908vn....
sRequests holds my data (sUser=user&sPass=pass&iCheck=34564).
Edit: My client code was not public, compiled to an app.
Related
I need to call a web service from my client side JavaScript code (which will run as a web page is loading). I understand there are libraries for doing this like this one, or I can just use straightup jQuery as described here.
But one concern I had was authentication. I need to send the webservice a username/password or a authorization header as described here. Now if this will not come from the user, it seems that it needs to be stored somewhere on the browser side code in order for it to be sent when that code runs (client side).
Won't this then be in the clear for all to see just by doing a view source on my page? If so, how can I prevent this?
Well you can encode the user name and password so if someone sees the view source of the web page it will show the encoded credentials.
To encode/decode the credentials you can use the atob and btoa Javascript functions. They are present in the JavaScript implementation of most browsers. See this link: https://developer.mozilla.org/en/docs/Web/API/WindowBase64/Base64_encoding_and_decoding
When sending the credentials to the server you can decode the data before sending the credentials.
To ensure that the credentials are not read during transmission, they should not be sent in plain text. HTTPS can be used to secure the web service requests.
I've been tasked with creating an LDAP authentication on a front-end Javascript application.
I am extremely limited on time and have a very small toolset. The toolset is the front-end javascript application and an available C# application which I can make post and get requests to.
I was thinking I could simply make a call such as https://mybackend.com/authenticate
Where I would post a username and password.
And on the backend this would return whether or not the user was valid in the AD. Which I can then use on the front-end to ensure the user has logged in.
Is this approach extremely unsecure or does it have flaws? I'm thinking that if I am posting to the backend above not much will be exposed.
Any tips would be immensely helpful.
Is this approach extremely unsecure or does it have flaws?
This is not insecure, it's the normal way you would do it. One could add more security by adding a CSRF token, which would be validated on the server for any form submit.
And yes, you should send all the data over HTTPS, this will encrypt the payload.
What you are doing is normal for front-end JavaScript framework like Angular. As long as you use Https, you should be ok.
Only issue is how you will handle the subsequence page requests.
There are two ways to handle it –
Easiest way is to use ASP.Net MVC as login page, and use Cookie Owin Middleware. Since same cookie is sent back to server on API calls, you do not need to do any extra works. You can download my sample code at GitHub - OwinAuthenticationService.
Another way is to use Bearer Token in which you will have to send the same token back to server on every page request.
All method are insecure.
Especially without HTTPS.
But you can put the Authentications in the header of message and use a token generated with a key that only server know.
I would to ask a few questions to better understand some procedures. I'm trying to write a web api project which will be a backend for both web and mobile clients.
The problem that i've in mind is about security. I don't want to use Identity or any other providers. I want to use my own database user and role structures.
Only authenticated client applications should be consuming my application. So that anonymous applications should not consume it.
So what should be the approach ? I 've written a custom AuthorizationAttribute and check some custom headers like "AppID","AppSecurity" key which i store in my own database and if the client sends the right appId and the key it means the app is authenticated to consume the API which does not sound very secure to me.
Another issue is that ; Lets say i've developed a javascript web application and i've to first authenticate the application itself before making GET/POST/PUT/DELETE etc requests which means i've to add some kind of authentication data like username, appkey, password in one of the js files for sending the "AppID" and the "AppSecurity" keys in the header. A client who knows how to use some developer tools or fiddler can easily capture my header values that are being sent to the server side? Even if i pass authentication values on the body of my json request it still can be found on the js files that are sent to the client. I'm also confused about that tooç
So basically i want to build a server side api that will serve the data and get data from the authenticated client applications only. What i need is a simple example for that without using any identity providers.
I have a PHP app that renders HTML pages for a social media application that I'm creating. Then, JavaScript initializes and makes things interactive. The PHP side of things logs into a separate webservice with curl.
Now, I can't figure out a way to share the session started in PHP with JavaScript, so when I make a AJAX request in JavaScript to the data server, its authenticated.
Is there a way to share a PHP session with JavaScript? Or to share authentication initially created with PHP with JavaScript?
I would say it sounds like there is something wrong with your architecture. In my opinion, the web server itself, should be the only peer providing data to the client/browser. It's a two party conversation only.
When trying to hit a third-party server from the browser, you violate the browsers Same-Origin Policy, unless you specifically allow CORS by explicitly setting various request and response headers. - and you would only do so in very special situations.
The best solution might be to create proxy services at the web server, that can be hit directly (locally) by the browser. The web server can then (acting as controller) forward the data-request to the data server (model) and finally return the response to the browser (view).
You can read out the session cookie set by PHP (SID I guess) through JavaScript containing the session ID.
When you make a query, use
http://example.com/?sid=SessionID
So now I am pretty much sold to the idea of having pure html+js front end where all processing happens at client side browser and the backend provides all the data in JSON/xml/other format and so on.
Here's the dilemma,
For authentication, I am using OAuth2 Bearer token which gets generated when user authenticate using username and password (for e.g. at login stage).
There is an extra security for which clientside application (i.e.a front end web server or mobile app) that is making request to this WebAPI. When it makes the initial request, it passes "client_id " and "client_secret" to make sure the client is app is authorized to make this request to back end server.
In traditional .NET way I would store the encrypted clientid and key in web.config and my C# (Or VB.NET) code would retrieve it and send it over SSL to the server. So in the manner the client_id and client_secret is not exposed in rendered HTML (for e.g.) to the client side browser.
In pure javascript environment how can I secure my client_id and client_secret (or any other sensitive data for that matter)?
Thanks
I don't think you can secure your "secrets".
HTML5/JS code is pure text, anyone with a text editor can see it. What people normally try to do is obfuscate their code by using javascript minifiers/compressors; see here for a good discussion. The practice is called Security through Obscurity. But note that obfuscation is not security. Given time and effort, a determined "hacker" will eventually find your secrets. Another step you can take to deter, delay and frustrate such attacks is to spread bits of your secrets in the code, in different modules, etc. Having said that, you'll need to write code to assemble them at some point, so again, no real security.
I have a similar problem because I wanted to use a "shared secret" with the server so I can hash my client requests such that they are tamper-proof and can't be recreated without the attacher knowing the shared secret. Unfortunately I had to give up on the idea, since I realised I couldn't keep it secret enough.