For my rails application I use data-attributes rather extensively, as it was easy and the site was never expected to be finished or published, simply something I did for personal fun. A short example of the raw HTML would be
<span class="player-name" data-id="4" >Example Player</span>
I then could access the 'id' in coffeescript in the following way:
id = $('.player-name').data('id')
I was wondering if this utilization of data-attributes could potentially make the site susceptible to attacks through people editing the data-attribute in their developer console. Also if there is a better approach to accessing data in jQuery I would greatly appreciate it if someone could point me in the right direction. Thanks!
Yes, you're right. People can modify this. But this is hardly unique to data- attributes; people can modify anything and send any request with any parameters to your server.
You should always validate data coming from clients. Always, always, always. Too often have I seen applications where I have an url such as http://example.com/orders/42 where modifying the 42 to 666 resulted in me viewing a stranger's order. Oops! With AJAX requests it takes a bit more effort to fake data, but not much. People can (and will!) modify anything on your client-side: URLs, HTML, JavaScript, CSS, etc. so it's always wrong to rely on that for security.
In practice, this means that after getting an object from the database in your Rails app you should always check if the currently logged in user is allowed to view this object. For example, in a controller you might do something along the lines of:
def show
# Fetch it from the DB
some_object = SomeObject.find params[:id]
# Make sure the current user is authorized!
raise if some_object.player_id != logged_in_player.id
# ..your controller code..
end
I don't necessarily recommend you do this "manually" like in the above example. For Ruby on Rails there are two well-known gems to help with this:
Pundit; this is what I would recommend. It's simple, elegant, and flexible.
CanCan; also used a lot. It's more complicated than Pundit and I've found it doesn't actually provide more features. Your mileage may vary, though.
Related
I'm creating some default "drag and drop" templates for our developers, and one section is the required tags. Most of the tags reference a variable: nice and easy. But one wants to reference the resource itself and I cannot figure out a way to it. Does anyone have any suggestions?
The tag itself is called "Context" and it's value should be the "type" of the resource it is in, e.g. "Microsoft.Web/serverfarms". This is desired to aid with billing. Obviously I could either create a different template per resource type (not ideal considering the number of different resources) or rely on the devs to update the field manually (not ideal either as relying on them to add the tags manually hasn't worked so far in a lot of cases), but I am trying to automate it.
Extrapolating from the [variables('< variablename >')] function I did try [resources('type')] but Azure complained that "resources is not a valid selection". I thought it might have complained that it couldn't tell which resource to look at, but it didn't get that far. Internet searches have not turned up anything useful so far.
I can't find a way to do this cleanly either (I hope someone corrects me though! This is a topic for us too). The reference and resourceId functions look promising, but both are unavailable inside of the resources block, would require some parsing, and also require the api version, which you probably also need to vary by resource and so you're just back to where you started. ARM won't even let you use a variable for the resource type property(probably a good thing), so that option is out too.
As such, you'll either have to live with your team having to replace that chunk of text manually or pursue some alternative.
The simplest thing that comes to mind would be to write a script in a language that understands JSON. That script reads the template, adds the tag to the resource, then saves the template again.
A similar approach would be to do it after the resources are deployed by writing a script that loops through all resources and making sure they have the tag. You can use automation to schedule this on a regular basis if you're concerned about it being missed. If you're deploying the templates using a script, you could add it in that script too.
There's some things you probably do with nested templates, but you probably wouldn't be making anyone's life easier or making the process more reliable.
This could be achievable potentially through some powershell specifically around Resource and Resource Group. Would need to run a Get-AzResource either at the subscription or potentially just the resource group level. Then pull the ResourceType field from the object return and use a Set-AzResource command passing in the ResourceID from above and the new tag mapped to the returnedResourceType field.
Nowadays, we always think like "send your data to a server, it computes it for you, then send you back the response".
But imagine something else : i want my client to compute the data itself.
The question is : is there something like a universal protocol to send actions rather than data through http ? So that the server can send the action to the client, whatever system it uses. If it does not exist, what are the technical difficulties you can face creating this kind of system ?
I'm talking about "static" actions, like mathematical functions for example.
You're unfortunately going to run into a problem pretty quick because, technically speaking, a universal language is impossible. Systems are going to have different architecture, different languages available, and different storage means. I believe what you intend (correct me if I'm wrong) is a "widespread" protocol. One way or another, you're going to have to drill down based on your personal use-case.
For a widespread example, you could keep a set of JavaScript files with functions server-side, and refer a web client to the one they need to run it by loading a javascript file during some event. Pass the location of the file and the function name, load it using the link above, then call the JavaScript function by name to run it. I could see this being an admitedly somewhat roundabout solution. This also may work in Java due to its built in JavaScript engine, although I haven't tested it.
Beyond that, I am unaware of anything particularly widespread. Most applications limit what they accept as instructions quite strictly to prevent security breaches (Imagine a SQL Injection that can run free on a client's machine). In fact, JavaScript limits itself quite severely, perhaps most notably in regards to local file reading.
Hopefully this helps with your ideas. Let me know in a comment if you have any questions/issues about what I've said.
I want to Obfuscate + Minify my Angular JS code in order to not make it public and if someone tries to decode it, then make it a hurdle. Code is running up on the server.
Note: In future we are planning to shift http to https.
I have seen a lot of options like Gulp, Google Closure Compiler, UglifyJS etc and many tool which a user can download and obfuscate the code like jsob, javascript obfuscate etc.
I need a suggestion and have few questions.
What is the more better approach apart from encryption?
If I shift to https shall I still require obfuscations?
What are the better and easy approaches with pros and cons?
If I use a tool like JavaScript obfuscate, then what will be its pros and cons? Am I able to get It back, I mean decode?
Or If someone is able to look into gulp file will it be easy to get my code?
1 - It really depends on what you are trying to achieve. If you really want to protect your code to hide your business logic, you should go for a resilient solution, instead of relying on a minification or obfuscation tool per se which is far too easy to defeat.
2 - Https simply means that the communication between your browser and website is encrypted. Https can also be decrypted, so it would make sense to apply other protection mechanisms
4 - JavaScript Obfuscator and several other tools do not protect the code, they are simple obfuscators and so they can be easily reversed in minutes and that's why some people think it's not worth protecting code on the client-side. In fact, you can get most of the original code using a simple JS optimizer. ClosureCompiler and UglifyJS have precisely this different approach, they reduce the size of the code and optimize it, they do not offer code protection.
3, 5 - I found this blog post from js13kGames competition creator quite useful for my case. He suggests a solution that seems to be more appropriate - Jscrambler. IMO you should give it a try as it combines code transformations with anti-debugging and anti-tampering features. You can also lock your code to a predefined list of domains or set an expiry date to deliver expirable demos, for example. Maybe it could be a fit for your case too as it supports Angular.
I've found a nice solution using gulp-uglify.
If you use implicit anotation, first use gulp-ng-annotate for not losing service names on uglify process.
So I've gotten very familiar with Javascript MVC's over the past few weeks. Now I'm looking to learn the how to program a backend(specifically using asp.net MVC's implementation). I'm learning about the razor's view engine etc.
One learning block I'm running into when reading up on examples and tutorials is that I am thinking to myself "well..can't I just do that in the front-end with javascriptMVC" for most of the logic, and If I need to talk to a database I can just use a JSON call. There must be some value in back-end coding but right now I don't see it(hoping to get that solved).
The client is always exposed to attackers, hence you can never trust the code.
In other words: Any security-related things, verification and validation logic belongs to the server, all authentication and authorization stuff, … and: when you need to make sure that there is one reliable instance to decide some things, e.g. on prices, discounts, and so on.
There is a saying in web programming, and that is: All input is evil.
So whatever comes from your frontend (which basically is your JavaScript application) should be handled with care. Always black- or whitelist input, encode it, transform it, check it, and so on … and the only place where you can do this reliably, as it's the only place that is under YOUR control is the server.
Moreover: Never put secrets into the client, such as credentials (for your database, e.g.).
Hope this helps.
I'm looking for best practices for using the same data in different places without repeating yourself - this could include configuration or business rules.
Example 1. Data validation rules where you want to validate on the client using javascript, but you want to make sure by validating on the server.
Example 2. Database access where your web server and your cronjobs use the same password, username.
Ease of processing and a human-readable solution would be a plus.
Encode your data in JSON. There's a JSON library for pretty much any language you'd care to think of, or if not, it's pretty easy to code one up. If JSON is not enough, perhaps look at YAML.
XML is pretty globally used. Easy to read, easy to write, and human readable. If you're concerned about the space overhead (which you actually aren't if you want human readable) then just compress it before you send it out, XML compresses quite well.
See answers to this question. I think they are applicable here, especially the one with a DSL.
As much hate as they get, for sharing data validation rules, I'm going to have to say Regular Expressions.
I know, I know, everyone hates them, but they are (generally) language-agnostic.
Use O/S Environment Variables (envvars) to store application configuration info (such as db passwords)
Validation rules often require logic. You could write your rules in JavaScript, and then run them in the browser, server (using Nashorn), and database (PLV8 with Postgres).