Integrating web app with chrome extension - cookies

I have created a chrome extension which gets data from the current active tab in chrome. I send the data to my webapp via an API which stores it in the database.
At the moment my chrome extension has a fixed user_id. I would like to prompt the user the user to log in in order to get the correct user.
Is it safe/valid to check for cookie - if it exists use it otherwise prompt user to sign in via the browser?

It's probably okay, as long as you're not storing anything sensitive in the cookie like a password (obviously).
However, the appropriate way to accomplish this would be through something like oAuth. In this scenario your web app's API would be a oAuth consumer, and you would use the following library to authenticate in a Chrome extension:
https://developer.chrome.com/extensions/tut_oauth.html
This library will save an authentication to local storage for you. It's pretty easy to use. The difficult part is ensuring your web app's API supports OpenID. Google's AppEngine supports this pretty much out of the box with little configuration on your side, but this may not be the case with your API.

Related

In Squarespace Developer Mode, can one save the AWS CLI SDK to the website's server-side "Home" directory? If so, how?

The Current Situation
My Squarespace website uses client-side, custom JavaScript and JQuery injected into the Head section of a page as well as the Amazon Web Services Command Line Interface SDK. The custom JS, the JQuery and JS Libraries, and the SDK are loaded into the page Head each time the page is loaded.
That Is Objectionable
The SDK uses two predetermined, static, handshake credentials to connect to the AWS server. They are stored in a file, "credentials," in a hidden directory, .aws, created by the SDK when it first loads. At that point, however, they have no values.
The Situation Exposes Supposedly Secret AWS Login Credentials To A Potential Hack
Currently, it is necessary to set their values programmatically when the page loads by executing a CLI "updateConfig" command in the custom JS. The credential values are thus in a plain-text config file client-side.
As such, they are not so secret. Any site visitor who loads the page in his browser could use the browser's developer tools to view the source code and, potentially, discover the supposedly secret credentials thus compromising the security of the AWS account.
One Ought Not Put The Secret Credentials In Client-side JS
For that reason, AWS rather forcefully insists that one not put the credentials in client-side source code. The preferred method is to instantiate the SDK on the server-side and set the credentials one time only. Thereafter, the hidden .aws directory and the credentials file persist server-side at the root level of the website's Home Directory.
The Problem
So the problem is to load the SDK in the server-side Home Directory where it will persist over the site's lifetime.
The Question
The question is on a Squarespace website can one load the SDK server-side at the root level on the site's Home Directory. Can it be done in Developer Mode? How?
Unfortunately, Squarespace doesn't support the use of server-side/back-end code:
You can't add server-side code. Server-side code is handled by a server, not by a browser, and includes:
- PHP
- Ruby
- Ruby on Rails
- SQL
That would also include server-side JavaScript/Node. Because Squarespace only supports the front-end addition of HTML, CSS and Javascript within Code Injection, Code Blocks, and Developer Mode, you need to use front-end JavaScript in order to utilize third-party APIs (which is what you're doing currently).
Enabling Developer Mode only exposes template files for the site. Beyond the JSON-T templating engine, Developer Mode doesn't enable any sort of server-side logic or requests to take place. Therefore, it seems the answer to your question is no.
A potential alternative solution may be to use Google Apps Script or Google Cloud Functions instead, storing the credentials in the code there, and making a front-end request (via JavaScript on your website) to that endpoint in order to perform the handshake and get back the data you need.

Using Delphi to send email by web service (without leaking credentials and without user interaction)

I have a Delphi application, that needs to send a generated PDF file by email to one recepient of a predefined list of recepients.
I do not want to mess around with MAPI (not all customers have configured this)
I do not want my customers to enter their mail account details (this means SMTP is no option either)
Therefore I consider to use / setup a PAAS web service to receive the email text, the pdf file and the index number of the recepient to actually do the work.
My question is: Does an out-of-the-box solution exist to do this in Delphi, or what would be a preferable way?
For instance I considered using Google App Engine but there seems to be no builtin support in Delphi. I would prefer an out of the box solution or a tested solution with decent documentation. The server part should be as simple as possible.
Edited: Some clarifications:
The resulting exe is installed at the customer computer. I think setting up an extra mail account therefore is no option, because someone could extract the credentials from the exe and abuse the mail account. The same seems to be true for web services that provide only one (login/password) access.
Using OAuth2 seems to be no option either because I do want to send the email without user interaction.
If credentials need to be saved in the executable, and the existing answers suggest so, they should at least provide only very limited rights.
Is this solveable at all?
Is this solveable at all?
No.
If you require that neither the user (by filling in a login form, as is the case with OAuth 2.0) nor the program (by providing hard-coded credentials) authenticates with the web service, the communication with the web service can not be secure.
I suggest to re-think the security requirements and make them much clearer in your question.
To send mail you can use a webservice like http://www.mailgun.com/ or http://aws.amazon.com/ses/
They provide you with a http(s)-api that you can use to send email messages.
You can use Google App Engine with some programming in Python, PHP, Go or Java:
define a HTTPS address where your GAE application listens for POST requests
POST the PDF and the Email text with TIdHTTP
receive the PDF amd theEmail text in the GAE HTTPS server and forward it to the recipient
Here is an excerpt of a Python example for Google App Engine which handles a POST request
class Guestbook(webapp2.RequestHandler):
def post(self):
self.response.write('<html><body>You wrote:<pre>')
self.response.write(cgi.escape(self.request.get('content')))
self.response.write('</pre></body></html>')
Regarding OAuth: GAE supports OAuth but it is not required.

How to handle client authentication for secure web service in Delphi?

I have a SharePoint server running on my network and I am trying to build an app in Delphi which allows me to access the various SharePoint Web Services hosted there.
Running my app on the same network as the SharePoint server works fine, however, when I attempt to run it on a VM which is not part of the same Domain I can't get authenticated. I was looking for some advice as to how I should be handling authentication for this type of scenario, more specifically, should I be prompting the user for their credentials or is there some built in security model I can use for this?
Ideally I would like to try avoid dealing with Usernames & Passwords in my app and let the OS handle that sort of thing, however, at the moment I can't seem to see any other way around this.
After some investigation, for my particular scenario I decided that the best approach would be to use WinINet. I chose this approach over Indy because after some thorough investigation I found Indy did have some bugs & also it didn't have all the authentication handling we needed built in.
WinINet supports prompting for credentials & automatically authenticating across the wire. See Handling Authentication.

How to pass login and password data for a web app to a desktop application without causing any security risks

So I want to do the following:
A person registers online and selects their login and password for a desktop and web application (same login and password for both applications)
They then download the desktop application (written in C++ with Qt as it's cross platform)
Then the login and password is automatically passed to the desktop application without the person needing to enter this data. The login and password is used to authenticate with the server.
Each version of the desktop application needs to be individually coded with the person's login and password based on the fact that they signed up on the web page.
So here is a more simple explanation:
1. The user signs up on the web site and choose login\password
2. The user download desktop client on his computer
3. The user runs desktop client (C++ binary) and it asks for a login/password from the step
I would like that software fill in login/password automatically on step 3 for the first time. Is it possible? How would it be done without security risks?
The main problem is, that anyone could execute the program and gain access to a user account. I would suggest using a one-time login for first authentification with random tokens and after the first start, get the user/password information through an ssl-connection. After that delete your one-time login token and replace it with the actual login.
I don't really know whether you're asking for precise code examples or just want to have a basic concept... But anyway, storing login-data in the application itself is a security risk.
Have you look at HTTP Authentication?
I do not fully understand the download process of the QT app, but, if you use a Basic/Digest Authentication on your web server, propagating the authenticate token will be easy and safe.
Basic use a 64 base encoding, Digest a MD5 hashing. A lot of library implements those steps out there (Spring Security and Shiro in the Java world).
I saw two ways:
the server can provide a user with unique link for downloading installation package. The server patches that package by unique one-time password. So client will be able to login for a first time
the browser collects some information about a user's computer. For example, IP, MAC, OS Version, etc. Then it calulate digital sign of the computer based on these data. The C++ binary do the same. You can use that digital sign as one-time password.

Integrating authentication between a web app and desktop app

I want to upload a file to a website via a desktop app and then take the user to the website. The website has a web service, but requires authentication as does the web site. Is there a way to do this without forcing the user to authenticate twice (once in the desktop app and once in the web browser)?
Unfortunately, you can't prefill an input of type file for security reasons, which makes sense since the user won't want you uploading arbitrary files from his/her computer. But if they have a desktop app, is there some way around this?
Or maybe make the user log into the web app first and then the authentication cookie can be reused?
Any other ideas?
Thanks,
Ben
I would use the dekstop app as a client to the website app via an api.
So, login via the desktop app. The api returns a authentication token (as Carlos suggested) which might be a md5 hash stored in your database for a certain period of time, possibly matched to the clients ip address.
The desktop app can then make calls on the api (like uploading a file) as a authenticated user (by using the auth token).
When loading the website, perhaps the url is http://website/login/{auth_token} where the auth token is added to the url. The api can check to see if its a valid auth token and consider the user logged in.
You could generate an authentication token that could later be used on the website.
It all depends on the type of authentication of the service and the site. Is it integrated Kerberos, WS-Auth, is it Basic/Digest HTTP, is it forms/cookie ?
This answer will most likely not work in the very general users-on-the-wide-open-web scenario, but in intranet contexts, using Windows Authentication (on an ASP .Net solution), would provide this.