I have two applications one is a business process management (BPM) & the other is a document management system (DMS) , both systems exposes web services to enable integration with other systems. Both system provide a master login username and password to provide JSON API Authentication. for example to start a process ("process1") inside the BPM ; the DMS can send the following API call
/jw/web/json/workflow/process/start/process1?master_username=BPMadmin&master_password=982716171717&loginAS=currentusername
and same apply for calling DMS web services.
The limitation in this security approach is that i am unable to call any of the DMS or the BPM web services using JavaScript and consume the returned JSON using javaScript, since if i follow the javaScript approach i will be exposing the master_username & master_password to the end users and they can manually modify the LoginAs parameter to other usernames and perform actions they are not authorized to do.
so my questions are:-
Can i make the web service calls secure using JavaScript?
second question what other security approaches i can follow to make the web services calls secure using javaScript? baring in mind that i can modify the webs service security to other approaches rather than using master login username and password, but this might require more time and effort from my side?
Thanks in advance for any help
Best Regards
First of all JS is client side and does not include any special security/magic/irreversible functions, like browser aided crypto engine, high grate SPRNG for key generation and so forth. So long story short anything you do with js is not secure it can be obfuscated but it will be NOT SECURE. That is the point you already made. Another more approach is to use your server as 'proxy'. So lets say You are designing an JS aided gui and show some documents ro so, then you make an AJAX request to your app server (not BPM nor DMS) and it acts as proxy that will do the authentication against DMS and call WS and then return the result back to your JS :) So your setup would look like JS (session)-> App (ws auth)-> DMS -> App (sesion)-> JS (I assume you have authenticated user and we'll use users session as JS <-> server secure channel, if not you will have to incorporate some other js auth mechanism maybe one time pass or something but it will be easy because it is your system). And voila. Only security consideration is to not allow anyone to call your servers proxy site :)
Related
People need to log in to start using my app. They can register themselves on my website and their passwords are stored using Bcrypt. When they login in the app I transfer the password as plain text in a GET request (https://website.com/file.php?pass=password) to a php file which is using Bcrypt again to compare the password to the one stored in my database. My website uses a SSL certificate and with that a HTTPS connection at all times. So my NSURL starts with a HTTPS request. My question is, is it safe enough this way or is it completely unsafe? If so what would you suggest to validate the login of the user?
I think that using HTTPS is a great start. As zaph points out, you might want to check to make sure that your server is using TLS 1.2.
I agree with SLaks, though, and advise against GET request. Section 9.4 of RFC 7231 warns "Authors of services ought to avoid GET-based forms for the submission of sensitive data because that data will be placed in the request-target. Many existing servers, proxies, and user agents log or display the request-target in places where it might be visible to third parties. Such services ought to use POST-based form submission instead."
As you're thinking about NSURLSession security, I'd suggest that you make sure that you do not do any caching during user authentication, perhaps even using an ephemeral session, so that this data that you've gone to such lengths to encrypt isn't unintentionally stored elsewhere unencrypted.
I might also suggest watching WWDC 2015 videos Security and Your Apps, Privacy and Your App, and Networking with NSURLSession. These don't tackle your question directly, but they do touch on some some broader security/privacy issues.
HTTPS is safe if the server is using TLS 1.2 and perfect forward secrecy. Also if the server is using 2-factor authentication and the second factor is well controlled.
But you also need to pin the certificate in your app to prevent MITM attacks.
I'm about to implement a web application (back office for an existing app.) using the ASP.NET Core framework. At the moment I'm thinking about on how will I authenticate the user. The main database is using MySQL (not supported on this framework), so I will access the database troughout an existing PHP SOAP API.
Is there any way to implement a token based (OAuth) authentication knowing that the data access will be done trough a SOAP API ?
You can take a look IdentityServer3 in combination with the default OpenID middleware. You can completely separate the authentication logic from your application. Your application will trust the tokens generated by the identity server. The same as signin in with facebook/google/linkedin accounts etc.. using your own secure ticket provider. Identity Server supports customization so you can use the datastore of your choice. It is also possible to use your identity server for a various set of applications as long as they are "known" by your identity server. Definitely worth the investigation if you ask me.
https://github.com/IdentityServer/IdentityServer3
I am newbie with CAS Server, I found it is a single sign on server between different application in terms of technology like php, .net & java. I explore it but even though there are some questions yet not clear. Before ask my doubt, I tell what am I trying to achieve?
I am using a gwt based application, Now for some of the features, development is in a php technology. It should get some session data from existing java application. another approach to customize CAS like integrate a web service layer for authorization, instead of using its existing like query to db.
The doubts are:
1) Can I share a session data between Java & php application using CAS?
2) is there any security issue while passing a data using CAS server?
Thanks in Advance.
Sharing session data accross application can be addressed by mechanisms not linked to CAS. Though, when authentication occurs in CAS server, user data are retrieved from various data sources and these user data can be pushed to client CAS applications through SAML validation and the appropriate configuration.
My company produces a program that, among other things, needs to connect to the company's servers for updates and e-commerce purposes. We've had this for a long time, but we've never figured out how to handle "proxy authentication", where a proxy server requires a name and password before allowing the program to access the Internet.
This program manipulates the HTML headers itself, as strings, and communicates through plain ol' sockets, so I need to know the actual details of the headers. In other words, we're not using a communications library (there are technical reasons for that, which won't change), so we need to know where to put the name/password so that the proxy server will recognize them.
All I can find through Google are descriptions of how to configure proxy servers for it, or how end-users should use them. Does anyone know where to find the low-level details that we need for this?
According to the spec if the proxy sends a Proxy-Authenticate header then your subsequent request needs to add authentication headers according to the scheme (basic or digest) that the proxy requires. That request would include the header Proxy-Authorization with the relevant credentials.
Hi I have a question regarding security, and web services.
I need a web service to provide an interface for the underlying mySQL database. I am trying to get a Blackberry Application to store data on the web servers mySQL database through a web service.
My question is, how can I ensure that the bb-application is the only thing that is using the web service? The web service will essential insert data into a table. I want to ensure that only the bb-application is allowed to use this service and not someone who figures out the service and starts spamming my table.
Any pointers, best practices or links are greatly appreciated.
Also what sort of web service is best in this scenario?
Take a look at basic authentication over SSL. Configuring the application to include the username/password in the header should be fairly straightforward and the SSL connection will ensure they're not being transmitted in cleartext.
Use net.rim.device.api.crypto.HMAC to implement HMAC authentication and validation. Establishing end to end SSL connections on a Blackberry can be problematic and dependent on wireless provider support unless your users are activated on a corporate BES (which I srongly recommend as part of the solution if you want robust security).
I am going to assume that the BlackBerry application is made by yourself as well. How you can then do this is by creating a sequence or hash that only your application can create, that the web service can verify. For instance, in the beginning of the process, or better, for each step the web service sends down a key sequence, which maps to an internal dictionary within your application on the method to make the unique hash.
The flow would then be as follows:
Perform data task in BB application
Ready to transmit data to web service
Create unique hash from data + your own information from the mapped dictionary
Transmit the data with the key
Web Service verifies the key. If validation fails, it discards the data completely, if succeeds, it will then do what it needs to do.
Continue.
HTH
Disclaimer: Assuming this is an open ended WS.
Also see my answer here.
I would go with a REST web service over HTTPS it would take your problems away. I dunno anything about blackberry apps so I can't give u any pointers on how to use HTTPS in that platform.
If you are creating a SOAP web service then you want to read about ws-security.
Others have indicated using SSL to secure the site. However, that is only one part of the puzzle. Kyle was close with the second, but didn't quite cut it.
The answer is that every single transaction which is posted to your web service must contain some type of authorization key. That key can be pre-shared and baked into the application OR it can be acquired through some other means and set up as part of the application install / configuration process.
Nearly all companies which provide web services online following this method. The idea is that regardless of the underlying protocol (ssl for example) you have to validate that the request is indeed coming from an authorized device / program. Some vendors have the users create a unique key for each user, some for each device, and others just 1 key for the entire organization. Regardless of how deep you take it there is in fact a key.
The key usually isn't that large. It might be anywhere from 15 to 40 alphanumeric characters.