I'm trying to make a program that can be hosted by many peoples, like an app.
The app use a REST API, so I must authenticate with Oauth,
and because anyone should be able to host the program, the redirect URI cannot be static.
Further, I don't want to use any server-side processing, which means only javascript for me.
Is it even possible to make a secure and working solution with non-static redirect URI,
and only using javascript, to work in a normal webbrowser?
So you use the information provided in the request to your app to indicate the URL for your app. For instance, if the request came to http://example.com/path/to/app and you knew in your app that /to/app was part of your routing infrastructure, then the path to your app is http://example.com/path/.
That is how I would determine it, using a serverside language.
Using a javascript library, which would be loaded from the server, I would either determine it like the above, or I would just hard code it on the generation of the javascript file (when you tell people where to download the javascript, it can use a form that requires their web address first).
Related
I am trying to access the HaveIBeenPwned web API for breached sites and emails, but I am being blocked by cloudflare's anti-DDoS protection. I've found that there are ways to get around this with Python and JavaScript, but I haven't been successful with my React/Rails app.
This post has the following quote: "Currently, they check if the client supports JavaScript, which can be spoofed." I haven't been able to find any other documentation of this behavior.
I need this information in the backend, so calling HIBP from the frontend is not ideal. Any idea how to hit the API from Rails?
If they want it to be used on frontend only, using it on backend can be tricky. You will need to create your own wrapper with, for example, puppeteer. And from Rails side execute command that will do some work in background. But keep in mind, it doesn't work very fast (can take up to 5 seconds per request), and it will block your Rails process.
I would start with single node.js app that will accept command-line parameters. Ruby isn't very good at advanced web scraping, so there are no any gentle solutions. Also, keep in mind that you don't have any guarantees. One day it can just stop working.
I have a JSP webapp developed in Eclipse as a dynamic web project.
we use a third party web application that invokes my application, I need to validate that only the requests that come from that application are allowed to create a new session in my application.
I´m tring to do it with javascript and thinking , as a last resource, to use a Filter class to know the request origin and define the behaviour.
the problem is that the user requires that the operation is done on the client side, meaning I have to use javascript or similar, I have read about document.referrer on JS, but so far nothing is shown on the console.
Anything that you do in the client using JS for handling sessions wouldn't be secure as it can be easily modified by a malicious user. Also, using the referer or any other http header params would be insecure as they can also be easily spoofed.
If this third party application is directly calling your application I imagine that you have some degree of control over it. Can you access and modify its source code or are you just using configuration params?
Ideally the third party application would use an authentication token on each request that it makes to your application. And these authentication requests as well as all the session handling logic would always be handled on the server side.
On the last section on Platform Security, it mentioned a way to secure the source code in PhoneGap apps.
Reverse engineering is a concern of many people that use PhoneGap since one can simply open an application binary and look at the JavaScript source code of the application. One could even go so far as to add malicious JavaScript code, re-package the application and re-submit it to app stores / markets in an attempt at app phishing. This practice could be undertaken with any application whether it is written with PhoneGap or otherwise since it is a similarly simple task to decompile either Java or Objective-C.
PhoneGap can actually get around this security concern since application developers can download JavaScript in their application at runtime, run that JavaScript, and delete it when the application closes. In that way, the source code is never on the device when the device is at rest. This is a much more difficult prospect with Java or Objective-C let alone the restrictions in the App Store around dynamically running Objective-C code.
However, I would like to know how can I prevent others to download my source code on server?
I'd suggest annotating your code and then running it through Google's Closure Compiler, which will obfuscate it and perform certain optimizations. This will make it very difficult for people to read your code, but beyond that you're just going to have to live with the fact that JS is a client side language.
How about the following pattern:
Embed a bootstrap JavaScript with your app that does enables user/device authentication against your server. Do what you can to obfuscate the bootstrap code.
Keep the main logic of your app as JavaScripton on your server (can be accessed by authenticated users)
After authentication, download the main logic JavaScript at runtime, run that JavaScript, and delete it when the application closes
Continuous upgrading follows painlessly.
I would suggest:
Obfuscate most/all of the JS code. Google's Closure Compiler is good option.
When App gets started:
Have some hashcode stored on device which needs to be verified before making a call to server for dynamic data fetch
During App startup, first push the App hashcode to server in order to verify the App authenticity and Server will check that hashcode in order to verify the legitimacy of the App
Once Server has verified the App legitimacy then Server can send another hashcode or keep using the same one. Plus server can set custom cookie parameters too...it all depends on the architecture of the App & Server communication. So set whatever is best to your needs
Once App legitimacy has been verified then all calls from device to server should contain the same hashcode or cookie and server will verify it first before answering to the call.
Rather then sending new js code , its better to push json dynamic data and keep the js code obfuscated on the device.
Our scenario:
Our solution consists of an MVC app which serves a single page javascript application, and an Asp.Net WebAPI app which is intended for use both as a standalone api and as a source of data for the SPA.
We have set everything up so that the two apps will share auth tokens and membership, so if we are logged in to the SPA then the same formsauthentication cookie will also allow us access to the API.
This works fine if you make API requests in the browser address bar, but not through AJAX. We have followed examples of setting up basic authentication using Thinktecture and if we hardcode username\password as an authentication header for our ajax calls then this works fine also.
My question is however, what is the correct way of persisting these details on the client side? Our only real solution so far would be to send down the base 64 hash of the username\password as part of the initial load of the SPA and then pull this out when needed. This seems insecure however.
So basically, just wondering what the 'correct' approach is in this situation... are we close or is there another approach that we have overlooked?
Thanks!
We're using the session token support from Thinktecture.IdentityModel and then making the token available to the client via a dynamically generated script.
Full details at http://ben.onfabrik.com/posts/dog-fooding-our-api-authentication
I also published a sample application demonstrating these concepts at https://github.com/benfoster/ApiDogFood.
I'm working on a web app that is mostly static - just HTML/CSS/JS + assets. I'm using a Rack server (Thin, actually) to serve it.
While the app is mostly static, there are a couple of server-side needs that have cropped up along the way. Since the app needs to interact with those needs via JavaScript, I've added Sinatra to the stack to allow me to easily set up some routes to serve as a simple API.
One such API call is to send an email - the web app needs a way to send an email to users. I set up a route (/api/mail) that can be called with a POST that includes a JSON object, and Ruby will fire off an email (via SendGrid).
Here's my issue - by nature, these API calls are public. Most of the time, that is fine - but with the email API, I want to protect it so that nobody can just start sending malicious emails with a simple POST, posing as my app.
Problem is, I'm not quite sure how to authenticate this. The web app itself is the client, not the user, so a password or API key seems worthless, since anyone could just sniff out the POST header and grab the credentials that the app is posting to the API.
Is encrypting everything via SSL my only option, or am I missing some glaringly obvious solution?
At the end of the day, anything you do can easily be scraped. I would do some aggressive rate limiting by ip and session, don't think if anything else would be possible (or effective)