• Replies 17 replies
  • Subscribers 0 subscribers
  • Views 68 views
  • Users 0 members are here
Options
3sides - Social sharing widget
Related

Display iSheet Data on Home Page/Wiki

Sean Pillai
27343

I recall that there is a simple way to display iSheet records on a site's home page (or wiki) in a table or single-item format.  I'm referring to data from each individual row as opposed to charts and other aggregate data visualizations.  However, I haven't been able to find the instructions.  Any assistance would be appreciated.  I'm trying to display iSheet data in a more user-friendly manner by, for example, placing the contents of each column in a separate row, with each iSheet row corresponding to a separate table on the home page/wiki.

 

Simplified example:

(1)  This is my iSheet record:

 

Client Name Client Jurisdiction Client Code Client Mailing Address Client Relationship Manager(s)
Acme Co. Delaware 1234567 123 5th Ave., New York, New York Bob Smith; Amy Jones

 

(2)  I'd like to generate the following on the home page/wiki (including a link at the bottom that would allow the user to edit that particular record):

 

Client Name Acme Co.
Client Jurisdiction Delaware
Client Code 1234567
Client Mailing Address 123 5th Ave., New York, New York
Client Relationship Manager Bob Smith; Amy Jones

Edit Record [THIS LINK WOULD TRIGGER AN EDIT OF THE RECORD

 

]]>

  • Andrew Quinn, this is some next-level stuff right here! I'm in awe.
    Thanks for sharing this!

  • Andrew Quinn Big NoNo?
    I wonder why this would be a big NoNo. HighQ saves api keys in an user accessable way as well. Just take the HighQ Drive Windows App (or any HighQ app) login and let it run. If you now make a memory dump of the app, you can quite easily find the api key there. So even non admin users can get a hold of the api key.

    This seems rather unavoidable, because any programm accessing the api needs that key somewhere in memory. So every programm running on a user's machine will expose the key to this user. Same with using the api in the frontend.

    Nevertheless I would advice against using the api in the front end. This is because the timeout for the refresh token is one year (!), so if the user does not log out properly this token could be used by an attacker.

  • Julian Redix, I was talking about the secret key#, not the access token. Also, without the secret key# the refresh token is useless.

    # When talking about secret key, I'm also including the client ID too. Having both allows the attacker to refresh and generate tokens.

  • If the attacker just has the client id and secret, wouldn't they not be able to do anything yet with them, because to actually get the token you also need to login with a highq account and then use the id/secret to get the token. To successfully execute the attack, they would need to make a fake form/page (could be on the highq domain) and have an authenticated user then log in and authenticate to generate the token which then the attacker hijacks.

  • Wondering if HighQ implements a feature where they provide a JS api hosted on the domain where it just re-uses the logged in session details to authenticate rest api calls from the front end, would it be better long term by simplifying usage for custom apps run on the domain front end. If the user logged in, they already proved they are a valid user, I feel like the rest api (if used from the front end) should leverage this and not need to re-authenticate with a token again. Tokens should be more for authenticating from external apps.

    If we compare with SharePoint platform, this is doable in both the on prem and online version. With on prem, it just works for GET and you can pass in a digest token (already available on the page) for POST. For online, you can use PnPjs and pass in a context object (also available with the page) to make rest calls. Super simple and no need to worry about oAuth tokens, though that is available too if you want to connect from external apps.

  • Andrew Quinn I was talking about the secret key as well. Every Program, which uses an OAuth2 API needs to have this in its memory (and so somewhat exposed to the user) otherwise it would not get an access_token or a refresh_token.

    My Point is, that HighQ exposes the secret key in this way, and they got a ISO 27001.

    As I said, just try to make a memory dump of HighQ Drive. You will find a secret key there.

    Ryan D'Souza I agree, an attacker would need user credentials to use the secret key. But if an attacker could get a refresh_token, this token would allow them to access HighQ even without user credentials.

    So in the end using the API in the frontend is not entirely risk free, but also not a gaping security hole. Because for an attacker to get the secret key or a refresh_token they would need to find an additional security hole (like XSS or malware on the users machine). And if one of those vulnerabilities is present, the API key in the frontend would be the least of your concerns.

  • Julian Redix, and those are all valid points, but you've taken what I said, out of context, and applied it to the process in general. What I was specifically calling out, in that post, was exposing the secret key in client-side (plain text) javascript. The client-side should just be responsible for generating the OAuth code, which it should then hand-off to a server-side process - that will have it's own security walls and mitigations - that will in turn use this code with the API to generate the access token, and return back to the client script.

    Ideally the server-side should be the one responsible for using the Collaborate API's (based on client's OAUTH code), and the client-side uses the server-sides own API's, obfuscating the use of Collaborate API's, and it's need for Collaborate tokens - which is basically what the Collaborate website itself is doing.

    Each environment has it's challenges when trying to protect and obfuscate security-related issues, but generating OAUTH tokens ALL in client-side (web browser) javascript, is fool-hardy, worst still when this js file is loaded by the website page from a CDN, like an S3 bucket, where the key is exposed for all to read.