I am making a online book reader and my problem is whatever i did to secure book data, it can be easily extracted through firebug.
I tried following things to protect my book content
sent encrypted data from server , and on client side decrypted the data and sent to html Canvas.
but this process also ddnt workout at the end i can get data from firebug.
Is there any way from which i can protect my content?
I can see only one solution that is sending images from server but this also i dont want because there will be too much load on my server. is there a better way to solve this problem?
I have heard about node.js, that it is a javascript based server. can i make a page from canvas(HTML5) at server side and send directly to browser?
If you deliver content via HTML (no matter how you create it) - it will always be visible to the end user via browser's special panels. In this approach all you can do is prevent the 'regular Joe' from simply saving the page or copy/pasting it somewhere else. Technically advanced users will be able to 'read' your content as they wish.
So, you will need to use some embedded objects, like Flash movie, which will load the encrypted text, decrypt it and display. They are not as easy to copy as the HTML ones, but still possible, if one wants it a lot.
Finally, even if you put all your text into images - there is text recognition software available, and your text will be parsed away within minutes of work. So, your only solution is to make it easier to pay you for unlocking the text, rather than hack it away with tools.
I think you just have to accept that any data sent from the server to the client is data that you have given up control over, no way around that. Even if you create a bitmap image on the server and send to the client, it will still be possible to OCR decode the image to get to the text.
Instead, perhaps, focus on methods for motivating people to pay or donate for the content. Or seek other revenue streams.
That being said, web-workers could perhaps be a way to hide data from the DOM as you ask. But since web-workers conversely don't have access to the DOM and hence the canvas, you will need to proxy your canvas calls and FireBug or similar tools will still be able to trace those calls. It would be an exercise left to the reader how to ensure that those calls doesn't contain data that can be easily comprehended.
Related
i have a bunch of websites of mine that need to call an external server asking for some data. This server contains sensible information such as discount codes that need to be applied on the website, based on what the user is doing.
Since i can't do a synchronous ajax call on users' actions (deprecated and bad practice), i'm doing it async everytime a user loads the page on these websites.
The call retrieves all the possible discount codes but i'd like people not being able to decode it and get them for free.
The server creates a json array and encodes it as base64, then the JS in the user browser will decode it (atob() function) giving me the json i needed to work with.
I'd like to apply an encryption to this like an algorithm for letters swapping or something. This means that even if the user reads my json result is not going to be able to read it BUT he could read it when my JS code tries to decode it (pausing with the debugger).
So my question is: could javascript obfuscation solve my issue? My JS would contain the algorithm to take my string back to its original form but the whole code is obfuscated therefore debugger won't work. Is that a safe approach to the matter? If not, how could i do it safely?
Summing it up, the system works like this:
1.User loads page in website
2.JSONP AJAX call asks all the available discount codes from my server
3.Server gets the list, makes a JSON of it and returns a base64 string of this json
4.Client gets this and when he clicks on something particular i decode the json and apply the correct discount based on calculations.
I hope it's clear enough for you to give some suggestions :)
thanks!
If you make your decryption on the Client machine, then there is no way of making it secure. You could apply obfuscation, or other means of hiding your process, but ultimately there is a point in the code which makes the decryption, and is available to the client. You should not do that on the client side.
You could maybe do this:
Website loads
It sends request for promo codes, along with the user details.
You send only data that is available for that user.
In this way you do not need to encrypt anything, but it will involve some rethinking and change to server side logic.
There is maybe another solution, which is hacky, and also requires server change.
Send the codes as you already send them, but send them incomplete. Maybe remove last 2 or more digits. Then the user requests to activate promotion, and sends the incomplete code. Then you look in your table code that starts (like '%'), and create the working code on the server side.
Just starting to use Highcharts. If I include data in an array within the javascript the data is available for anyone to download when they view the source. This would be the same when data is called, say, from a csv file. Is there a way of protecting the data against copying/download?
No, since HighCharts is a client-side JavaScript library, data available to it is also potentially available to the end user. There really is no way to "secure" it once the data reaches the user's browser, although you can use HTTPS, server-side authentication, etc to at least guarantee in principle that only the intended user receives the data.
If you need to visualize your data while keeping the actual raw data secure, the obvious solution is to render the data on the server and just (in the end) serve up an image or other static content to the user. But then you lose the nice, interactive charts.
You might be able to use Flash or Silverlight to retrieve the data, to make part of the process harder to reverse engineer. This is not securing anything, just making it a bit harder for a determined user.
On the other hand, a user can see the data anyway in the final chart. If they really want to download the data they could painstakingly identify each data point and create their own CSV file, right? You need to figure out what is good enough for your particular use case, and strike the appropriate balance.
Being that HighCharts is a client-side JS system, I don't believe there is a way to get data to it securely. If you just attempt an AJAX call to get data at runtime, a user can see that call and the response. As you said you cannot just populate a variable in the source, as it is visible there.
Try the render charts on server feature:
http://www.highcharts.com/docs/export-module/render-charts-serverside
I've been looking for better ways to secure my site. Many forums and Q/A sites say jquery variables and HTML attributes may be changed by the end user. How do they do this? If they can alter data and elements on a site, can they insert scripts as well?
For instance I have 2 jquery scripts for a home page. The fist is a "member only" script and the second is a "visitor only" script. Can the end user log into my site, copy the "member only" script, log off, and inject the script so it'll run as a visitor?
Yes, it is safe to assume that nothing on the client side is safe. Using tools like Firebug for Firefox or Developer Tools for Chrome, end users are able to manipulate (add, alter, delete):
Your HTML
Your CSS
Your JS
Your HTTP headers (data packets sent to your server)
Cookies
To answer your question directly: if you are solely relying on JavaScript (and most likely cookies) to track user session state and deliver different content to members and guests, then I can say with absolute certainty that other people will circumvent your security, and it would be trivial to do so.
Designing secure applications is not easy, a constant battle, and takes years to fully master. Hacking applications is very easy, fun for the whole family, and can be learned on YouTube in 20 minutes.
Having said all that, hopefully the content you are containing in the JS is not "mission-critical" or "sensitive-data". If it is, I would seriously weigh the costs of hiring a third party developer who is well versed in security to come in and help you out. Because, like I said earlier, creating a truly secure site is not something easily done.
Short Answer: Yes.
Anything on the users computer can be viewed and changed by the user, and any user can write their own scripts to execute on the page.
For example, you will up vote this post automatically if you paste this in your address bar and hit enter from this page:
javascript: $('#answer-7061924 a.vote-up-off').click();
It's not really hacking because you are the end user running the script yourself, only doing actions the end user can normally do. If you allow the end user on your site to perform actions that affect your server in a way they shouldn't be able to, then you have a problem. For example, if I had a way to make that Javascript execute automatically instead of you having to run it yourself from your address bar. Everyone who came to this page would automatically upvote this answer which would be (obviously) undesired behavior.
Firebug and Greasemonkey can be used to replace any javascript: the nature of the Browser as a client is such that the user can basically have it do anything they want. Your specific scenario is definitely possible.
well, if your scripts are public and not protected by a server side than the Hacker can run it in a browser like mozilla.
you should always keep your protected content in a server side scripting and allow access by the session (or some other server side method)
Yes a user can edit scripts however all scripts are compiled on the user's machine meaning that anything they alter will only affect their machine and not any of your other visitors.
However, if you have paid content which you feed using a "members-only" script then it's safest if you use technology on the server to distribute your members-only content rather than rely on the client scripts to secure your content.
Most security problems occur when the client is allowed to interact with the server and modify data on the server.
Here's a good bit on information you can read about XSS: http://en.wikipedia.org/wiki/Cross-site_scripting
To put it very simply:
The web page is just an interface for clients to use your server. It can be altered in all possible ways and anyone can send any kind of data to your server.
For first, you have to check that the user sending that data to your server has privileges to do so. Usually done by checking against server session.
Then you have to check at your server end that you are only taking the data you want, and nothing more or less and that the data is valid by validating it on your server.
For example if there is a mandatory field in some form that user has to fill out, you have to check that the data is actually sent to server because user may just delete the field from the form and send it without.
Other example is that if you are trying to dynamically add data from the form to database, user may just add new field, like "admin", and set it to 1 and send the form. If you then have admin field in database, the user is set as an admin.
The one of the most important things is to remember avoid SQL injection.
There are many tools to use. They are made for web developers to test if their site is safe. Hackbar is one for example.
Using Python, I built a scraper for an ASP.NET site (specifically a Jenzabar course searching portlet) that would create a new session, load the first search page, then simulate a search by posting back the required fields. However, something changed, and I can't figure out what, and now I get HTTP 500 responses to everything. There are no new fields in the browser's POST data that I can see.
I would ideally like to figure out how to fix my own scraper, but that is probably difficult to ask about on StackOverflow without including a ton of specific context, so I was wondering if there was a way to treat the page as a black box and just fire click events on the postback links I want, then get the HTML of the result.
I saw some answers on here about scraping with JavaScript, but they mostly seem to focus on waiting for javascript to load and then returning a normalized representation of the page. I want to simulate the browser actually clicking on the links and following the same path to execute the request.
Without knowing any specifics, my hunch is that you are using a hardcoded session id and the web server's app domain recycled and created new encryption/decryption keys, rendering your hardcoded session id (which was encrypted by the old keys) useless.
You could try using Firebugs NET tab to monitor all requests, browse around manually and then diff the requests that you generate with ones that your screen scraper is generating.
If you are just trying to simulate load, you might want to check out something like selenium, which runs through a browser and handles postbacks like a browser does.
I'm working on a new web app where a large amount of content (text, images, meta-data) is requested via an Ajax request.
No auth or login required for a user to access this.
My concern is that you could easily lookup the data source URL and hit it directly outside the app to get large data. In some ways, if you can do this you could probably scrape the static HTML pages elsewhere that also have this content.
Are there any suggestions on methods to obfuscate, hide, or otherwise make it very difficult to access the data directly?
Example: web app HTML page contains a key that is republished every 30 min. On the server side the data is obfuscated based on this key. In order to get the data outside the app you'd need to figure out the data source but also the extra step of scraping the page for a key every 30 min.
I realize there is no 100% way to stop someone, but I'm talking more about deterrence.
Use sessions in your webapp. Make a note (e.g. database entry or some other mechanism which your server-side code can access) when a valid request for the first page is received and include code in the second page to exclude the data when processing a request without a corresponding session entry.
Obviously the specifics on how to do this will vary between languages, but most robust web platforms will support sessions, largely for this type of reason.
If you are wanting to display real-time data and are concerned about scrapers...if this is a big enough concern, then I suggest doing it with flash instead of JS (AJAX). Have the data display withing a flash object. Flash can make real-time send/receive requests to the server just like AJAX. But the benefit of Flash is that the whole stage, data, code, etc.. are within a flash object, which cannot be scraped. Flash object makes the request, you output the stuff as a crypted string of code. Decrypt it within flash and display from there.
"Are there any suggestions on methods to obfuscate, hide, or otherwise make it very difficult to access the data directly?"
Answers your own question because if the data is worth getting it will be obtained because you are obfuscating is merely making it harder to find.
You could in the server side script processing the ajax and returning the data check where the request came from.