12

A 3rd party application we use is causing a great deal of issue because the user isn't clicking a Register button prior to clicking the Launch button or if they do click Register first, this Details page with both Register and Launch buttons refreshes and goes to their portfolio. They have to then re-find that item in their protfolio list.

The 3rd party application I believe is a .NET and is using knockout.js and does not allow embedding in Frames.

What are some options for providing guidance to the user or ideally make this process less painful?

I was hoping to provide an internal webpage that could send both Request and Launch actions with a single button click. I posted an earlier question Knockout data-bind click but couldn't get something to work.

There seems to be a bunch of similar questions on SO but I am not sure if these questions/answers are for automating button clicks on self contained applications as I want to do it if from outside the 3rd party application (do I even have access to their view model?). This app prevents embedding it in Frames.

  • Auto-click button element on page load using jQuery
  • How to auto click button in knockout js

  • Currently I have a link from internal website that opens two browser windows side by side. One goes to 3rd party and 2nd window with instructions. This is OK but we found people don't want to read. I really want to have a single button click or at least be able to send one request at a time from the internal webpage. Or perhaps overlay a joyride type guidance onto their site, if possible.

Here is the 3rd party button code

    <a class="btn btn-large btn-blue" href="javascript:void(0);" 
    data-bind="click: $root.clickAction.bind($data, ActionType)">
    <span data-bind="text: Title">Register</span></a>
Gabor Lengyel
  • 14,129
  • 4
  • 32
  • 59
jeff
  • 3,618
  • 9
  • 48
  • 101
  • 1
    I'm afraid you're out of luck since the 3rd party page that you're trying to manipulate protects itself from being embedded and, presumably, on a different domain. While what you're trying to do would be helpful to your users, it would rely on the same clickjacking techniques that the frame busting code in the 3rd party app protects against. https://www.hacksplaining.com/exercises/click-jacking – Stepan Riha May 28 '17 at 17:24
  • Could You include `js` somehow? (Via `html` template etc) – Hash May 29 '17 at 11:14
  • 1
    Sadly, I believe this is the nature of using a 3rd party application; you may gain time from not doing it from scratch but you'll deal with these limits and limitations or got stuck in a cost funnel paying them for customizations. Hacky / messy JS reach around code, might look good in the short term but will ultimately cost you more in the long run. I recommend disassembling and rebuilding to the point you don't rely on this third party. – Dr Upvote May 31 '17 at 17:57
  • 1
    @PhilCollins Exactly my feelings. I wish upper management would get on the same page. We have the capability to do in house but they always insist on COTS. Then we end up paying thousands to customize because it doesn't meet our needs or we just cram a different process down to the workforce to conform to how this COTS cloud based app works for all their clients. – jeff Jun 01 '17 at 14:24

1 Answers1

7

You basically want to hack the 3rd party app, but you control the environment, so it doesn't sound impossible. (I won't talk about whether I think it's a good idea, I will just list a few options you may have.)

Removing the X-Frame-Options header

You are saying the 3rd party app does not allow to be embedded in a frame. That is done by a response header, most probably X-Frame-Options (or it can be Content-Security-Policy: frame-ancestors, but it doesn't actually matter). All you have to do is remove that header and voila, the app can be loaded in a frame.

To remove the header, you will need some kind of a proxy. If the app is served on plain http, it is really easy, any kind of http proxy can remove the appropriate response header. If it is served on https, you have to do a few things to actually make it work (create a certificate authority, add the root cert to clients as trusted root, use the proxy to connect to the app and besides removing the header, replace the https cert with your own, which will then be trusted on your clients).

Note that this will weaken the security of the 3rd party app and it will make it vulnerable to attacks similar to clickjacking (and also pixel perfect timing and so on, all frame related attacks).

Inject custom script via proxy (edit: added this later)

With a proxy as described above, you don't need to remove X-Frame-Options. It's much better to inject your own javascript into the 3rd party application page, which can do whatever you want on the original page as it has full access to the application DOM. For instance it can change behaviour so that the appropriate buttons are clicked. :) I would do this if I wasn't able to install a browser extension on clients (see below).

Using a custom client

Instead of using the browser as the client, you could make a custom client that in practice acts as a browser, but disregards the above headers. This could also do the clicks you want without much hassle. The drawback is your users would have to start the custom client instead of using their browser to use the application. This is probably easier to do in a mobile environment where you have things like Xamarin and WKWebView.

Browser extension

An easier and probably more feasible variation on the custom browser idea is a browser extension. It could activate on the application url, and it could very easily do the clicks you want on the appropriate pages (browser extensions can request full access to pages regardless of headers). You would only have to install the extension once on clients. I would probably do this if I had to.

Gabor Lengyel
  • 14,129
  • 4
  • 32
  • 59
  • 1
    Thanks. Interesting stuff, unfortunately none are feasible options for me. – jeff May 30 '17 at 19:06
  • 1
    I will still edit my answer for possible future readers, because I got a better idea on the proxy side. :) If you can't do these because you don't control the environment (neither the proxy nor the browser), then I'm afraid what you want to achieve is impossible (it would then be possible for an attacker too, which to the best of my knowledge is not the case). – Gabor Lengyel May 30 '17 at 19:10