We have a business application that has a number of policy rules for which OPA seems well suited for. As a simple example: "an order can by modified from status 'X' to 'Y' iif the user is in role 'R'".
We'd ideally like to evaluate some of these rules both on the front and back end. In the FE (on the browser in an Angular app in our case) in order to provide a good user experience (make the field editable or not depending on the evaluation of the rule), and, of course, in the back end as well. Ideally, these rules would be in sync.
I see that "OPA is able to compile Rego policies into executable Wasm modules that can be evaluated with different inputs and external data." (link) There is also a JavaScript SDK so it seems like this could be a viable option.
I have not been able to find questions along these lines or references of anybody doing something similar and I am wondering if this is a good approach or if there may be better alternatives to the issue at hand.
Related
I am trying to build a puzzle game using HTML & JS. This is going to be a standalone HTML page. There isn't going to be a server side for this application.
Obviously, the game has an answer which the application will create at start time. Now, I wish to make this variable completely hidden i.e., not just hidden from user's view but also inaccessible to the user, even if he tries to read the page through Chrome's Developer Tools or such debug tools.
I'm looking for a solution using HTML5, JS ECMAScript 5+ & jQuery.
I remember reading something about Native HTML code (used for HTML File elements) which cannot be rendered/read even through Dev Tools. Is this any help?
Is there any way or strategy to achieve this?
NOTE: I am aware of <input type="hidden">. But that doesn't serve my purpose.
EDIT: As part of the game, the user makes attempts and the application needs to validate the user's input against this somehow-user-hidden answer variable. At this point, I believe there is no solution that's going to be completely airtight in the given constraints. Hence, I'm pursuing this from an academic interest. Does anyone have any other answers ?
Prehash your answer, hard code that into your page.
Then, when they submit their answer, run through whatever hashing pattern you did before hand, and compare the result.
It could theoretically be brute forced, of course.... if you had a few hundred years.
Javascript implementations of:
SHA-1: http://www.webtoolkit.info/javascript-sha1.html
SHA-256: http://www.webtoolkit.info/javascript-sha256.html
MD5: http://www.webtoolkit.info/javascript-md5.html
Edit:
An example would be:
Pattern: SHA-1(SHA-1(SHA-1(answer + salt)))
Salt: 982qx17wef7ddsbtxaewnsdufs (make something up, load it as an input type='hidden')
Result: (load it as an input type='hidden')
Request the answer
If SHA-1(SHA-1(SHA-1(attempt + salt))) === Result, they got it correct
Your can hash your values using MD5.
https://github.com/blueimp/JavaScript-MD5#client-side
I have a website that is only accessible via https.
It does not load any content from other sources. So all content is on the local webserver.
Using the Retire.js Chrome plugin I get a warning that the jquery 1.8.3 I included is vulnerable to 'Selector interpreted as HTML'
(jQuery bug 11290)
I am trying to motivate for a quick upgrade, but I need something more concrete information to motivate the upgrade to the powers that be.
My question are :
Given the above, should I be worried ?
Can this result in a XSS type attack ?
What the bug is telling you is that jQuery may mis-identify a selector containing a < as being an HTML fragment instead, and try to parse and create the relevant elements.
So the vulnerability, such as it is, is that a cleverly-crafted selector, if then passed into jQuery, could define a script tag that then executes arbitrary script code in the context of the page, potentially taking private information from the page and sending it to someone with malicious (or merely prurient) intent.
This is largely only useful if User A can write a selector that will later be given to jQuery in User B's session, letting User A steal information from User B's page. (It really doesn't matter if a user can "tricky" jQuery this way on their own page; they can do far worse things from the console, or with "save as".)
So: If nothing in your code lets users provide selectors that will be saved and then retrieved by other users and passed to jQuery, I wouldn't be all that worried. If it does (with or without the fix to the bug), I'd examine those selector strings really carefully. I say "with or without the bug" because if you didn't filter what the users typed at all, they could still just provide an HTML fragment where the first non-whitespace character is <, which would still cause jQuery to parse it as an HTML fragment.
As the author of Retire.js let me shed some light on this. There are two weaknesses in older versions of jQuery, but those are not vulnerabilities by themselves. It depends on how jQuery is used. Two examples abusing the bugs are shown here: research.insecurelabs.org/jquery/test/
The two examples are:
$("#<img src=x onerror=...>")
and
$("element[attribute='<img src=x onerror=...>'")
Typically this becomes a problem if you do something like:
$(location.hash)
This was a fairly common pattern for many web sites, when single page web sites started to occur.
So this becomes a problem if and only if you put untrusted user data inside the jQuery selector function.
And yes the end result is XSS, if the site is in fact vulnerable. https will not protect you against these kinds of flaws.
I am using nodeJS (server) and Dojo (client). I am writing a system that should allow users to create user-defined messages (they could be text-only email or SMS). I want to give a lot of flexibility. I would like to:
Pass the users a number of variables
Give the user a Web form
Allow the user to cycle through the data in the variables, print it, etc
The result of the script execution is a text file
This could even be used to allow them to create invoices. However, at this stage I am more focused on text.
I am thinking of allowing straight Javascript, and then eval() whatever they wrote in it. But... I am not sure.
What's the best practice solution for such a problem?
Don't use eval, read the following for why.
Why is using the JavaScript eval function a bad idea?
For JavaScript templating see the following list.
https://github.com/joyent/node/wiki/modules#wiki-templating
This seems like it would be fairly simple. But I have no idea.
For example, if the user was an Admin, extra functionality would be available. If the user was not, some actions would no longer be possible because the code was not generated.
Do I actually put Ruby inside the scripts and end the filename with .erb?
OK so from your comment above, I now get a feel for what you want.
It's a question of which side of the server to do things on. User credentials, of course, are handled server-side. Therefore, this would need to be communicated to the client, i.e. JS.
How you do that very much depends on your set-up. One conceivable model would be that your JS calls, via AJAX, a server-side script that reports back on whether the user is an admin or normal user. Perhaps the server-side script simply returns a string - user or admin.
Based on the response, you could load the admin-only functionality - i.e. JS scripts - that you need.
You could do this manually or, more easily, use one of the many JS loaders out there. AMD (asynchronous module definition) loads are very much the zeitgeist at the mo, so look into something like require.js or curl.js. A simply (non-AMD) option would be LABS.js.
I have an ISAPI DLL, an add-on to IIS. I build the installer for it using WIX 3.0.
In the installer project, I have a number of custom actions implemented in Javascript. One of them, run at the initiation of the install, stops any IIS websites that are running. Another starts the IIS websites at the end of the install.
This stuff works, the CA's get invoked at the right times and under the right conditions. but the logic is naive. It stops all websites in the beginning (even if they are already stopped) and starts all websites at the end (even if they were previously stopped). This is obviously wrong.
What I'd like to do is keep track in the session of which websites required a stop at the beginning, and then, at the end, only try to restart those websites. Getting the state of a website is easy using the ServerState property on the CIM object. The question I have is, how should I store this information in the MSI session?
It's easy to stuff a single piece of information into a session Property, but what's the best way to store a set of N pieces of information, one for each website? In some cases there can be 1 website, in some cases, 51 websites.
I suppose I could use each distinct website name to create a distinct property name. Just not sure that is the best, most-efficient, most efficacious way to do things. Also, is it legal to use slashes in the name of an MSI Session property? (the website names will have slashes in them)
Suggestions?
You might want to check out:
VBScript (and Jscript) MSI CustomActions suck
C++ or C# is a much better choice. If your application already has dependencies on the framework then adding dependencies in your installer is a good logical choice. WiX has Deployment Tools Foundation ( DTF ) that has a custom action pattern that feels a lot jscript. You could then create a dictionary of websites and their run state and serialize it out to a single property. On the back side you could reconsitute that collection and then act upon it.
Not to mention the debugging story is MUCH better in DTF.
There's a simple solution. I was having a brain cramp.
All of the items I needed to store were strings - actually the names of websites that had been stopped during the installation. I just used the Javascript String.join method to create a single string, and the stuffed that into the session variable. Like this:
Session.Property("CA_STOPPEDSITES") = sitesThatWereStopped.join(",");
Then to retrieve that information later in another custom action, I do
var stoppedSites = Session.Property("CA_STOPPEDSITES");
if (stoppedSites != null) {
var sitesToStart = stoppedSites.split(",");
....
Simple, easy.