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.
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.
In a nutshell, here is what I want to do:
Query a URL like www.mysite.com/?action=GetOnlineList&access_token=[Facebook Token]
Have that URL then return a list of all the user's Facebook friends online in JSON
I could then also do some other actions like "SendMessage" and "GetMessages" as well.
I've been reading up on this for a while and so far I've gathered that I will need XMPP/Jabber to do this, but I don't know exactly where to start.
Would creating an OpenFire server allow me to do this? I'm not familiar with XMPP at all, so I don't know how I'd be able to spit out JSON data from the server. Would I be able to setup queries like that on an OpenFire server?
You do not need to run a full XMPP server like Openfire, you want to connect to Facebook as a client (the same way users do).
There are two components you need; first you want some code in the browser to request the info from Facebook's XMPP server. However you can't connect directly to Facebook's XMPP direct from the browser (they only support XMPP over standard sockets), so you will also need something else: some kind of proxy on your server for your code to connect through.
There are some ready-made solutions for this, you can use Strophe.js with a BOSH connection manager running on your server. This allows you to log into the user's Facebook chat and fetch the info you need using XMPP. Make sure you use a standalone BOSH proxy, many XMPP servers (like Openfire, Prosody, ejabberd) have their own BOSH interfaces, but these won't allow you to connect to Facebook.
Since you say you require JSON, there are a couple of alternatives you might prefer to try, such as xmpp-ftw or stanza.io. Both of these let you deal with the XMPP server via JSON only, and xmpp-ftw is especially appropriate because it even includes the proxy part that you need (using node.js). It has well documented simple commands, the only thing you will need to learn are some XMPP basics, such as terminology (the "roster" is your contact list, and "presence" is someone's status, etc.).
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 :)
I am trying to design a system that will catch emails that are submitted to a server and process them. The processing will probably mean parsing metadata such as ip addresses, the email body and subject etc., and submitting these details to a web service.
I'd like to know what software (SMTP servers or similar) can either be integrated with, to perform arbitrary processing, or which servers will support forwarding to a web service (with queuing and retrying) out of the box.
Exchange is not a preferred option, as I'd like to keep that off the live servers.
It's probably easiest to just use any mail server and just process messages by pulling them directly out of the mailbox of the email user(s) on the system via IMAP or POP3 or something similar. Some mail servers are built with 3rd party access in mind where can register for events on new mail arriving so you don't have to poll for new messages. Different mail servers have different native access protocols and APIs. Exchange has IMAP and Exchange Web Services (EWS), Domino has C++/COM APIs, GroupWise a web service. And all are going to support some kind of default client access protocols like IMAP and POP3. The native protocols will give more features (like notifications), but for your purposes IMAP or POP3 may be enough.
There are a ton of ways to do this. A lot of this can also depend upon price, client, and the tech environment.
If this is a MS environment, and cost is a factor, one way you can do this is to use the built in IIS SMTP Service. The IIS SMTP service is most commonly used for sending emails, however, it can be configured to actually accept email. If you configure the service for a domain, all incoming email for that domain is placed in the mailroot/drop directory. It's placed as a text file ({guid}.eml format).
You can just use a Mime parser to parse these files, and then perform any business rules you want to on them. Since this is done at the filesystem level, you won't have to worry about intercepting any network calls. Just grab a file, parse it, and move to the next file. Then, have your app sleep for X seconds, and then check to see if any new emails have come in.
PS: shameless plug -- you can use aspNetMime for parsing these files, and extracting the data.
It might be worth your while to implement a simple lexing/parser to parse the header and look out for a specific header information. If it is an IP address, you may get away with it by using a regex parser.
Ideally, you should connect to the POP3 port of the server where the emails are stored and do a quick scan of the information, if the subject line or the message contains a specific string indicating that it is the email or even the IP address within the header, then you can retrieve that email and process it, this is where I think the lexing/parsing of the email would be done initially prior to pulling it down based on the criteria.
Bear in mind, you do not want to pull down an email that is not relevant, then how would you deal with it.
Maybe DotNetOpenMail might help, as it does not necessarily pull down all emails...
Hope this helps,
Best regards,
Tom.
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.