I am developing Desktop Application (which launches a zip containing index.html in browser). I want to secure that zip from end user so that zip's content can not be accessed without App.
NOTE: zip will consist couple of HTML, JS and CSS files and my app will consume it by displaying it's index.html file in browser.
I can encrypt my content but before using/launching content's index.html (through my app in browser) I will have to decrypt and extract zip into local file system. At that time user will get access of decrypted content. Is there any way to somehow keep decrypted content in in-memory from where browser can access HTML file and display them?
The options you have:
one of in-memory filesystems: the simplest and the least useful that answer directly the question "a way to somehow keep decrypted content in in-memory from where browser can access HTML file and display them". If you are going to use a standard browser, the content should be accessible to it, so the user can read it as well.
local web server: no much better, if you keep using standard browser. You can use something like electron's webview or alternative embedded browsers in combination with client certification. This way you can ensure the content is being visible only in legitimate browser. It can be done with nodejs (+ desktop integration) and will protect the content from non-technical users. Anyone with a bit of coding skills will be able to reverse-engineer it tho.
custom web browser: a regular compiled desktop app. You will need to implement your own browser, and can decrypt the archive directly in the app's memory.
Related
I need to create an HTML page that will generate a list of hyperlinks to the contents of the client side directory in which it resides.
This would allow HTTP browsing of a local NAS, where no web server involved and contents can change dynamically.
This might be extremely useful to anyone serving content on a LAN. We need this feature in an educational setting, where directory contents will change frequently. Making manual links would be prohibitive, and file browser access is also needed.
Our Digital Media program will be much obliged to anyone who can help us with a solution.
Without any kind of server/back-end code, an in-browser NAS file explorer is not possible. Client-side JavaScript only interacts with the client. It's possible for client-side JavaScript to contact a server, however, and retrieve information about that server's directory structure, but, of course, that would require a server where you say you can't have one.
As the title indicates i want to have a certain application get access to the local file system. To describe why i will illustrate my situation:
I am a running a IIS WebApplication with the C# MVC 4 Framework as backend module. The site solely consists of HTML, CSS markup and some JS. The page will be loaded in IE11+ (Edge) only. For the standard procedure of displaying and accessing data from as well as sending data to the server this works quite fine.
On a certain page I want the user to be able to upload a file using a simple file dialog, like the one you can initiate with a simple <input type="file"> tag. I also want to offer the posibility to download files from the server but need to know where files has been saved / will be saved to.
As described on a lot of different websites, just like this one here, the HTML5 File API does a great job but will not be able to return the full qualified filename including the local path directions, same for JS accessing the file object.
As my research confirmed HTML5, JS and also SWF (Flash) will not report detailed information because they are all sandboxed applications or restricted by RFCs. I already unterstood and appreciate the effort to secure my trips to internet.
But in this case do need the paths where a file was upload from and the file has been downloaded to.
So my question is, what is the best way to expose the full path directions for a up- as well as downloaded file to report them back to the server?
Is it possible to embed a SWF object inside HTML which will run inside an Adobe AIR sandbox or is a signed JAVA Applet still the one and only solution to accomblish this security breaking task?
A solution i would also apreciate would be the possiblity to ask the user to get access the file system, like you grant access to the web push service to receive notifications.
Also if there is a possible solution which may suite my circumstances please let me know by adding some simeple examples / revealing some factful links, thanks in advance.
I have a cordova app which offers a journal function. Users store questions and programmatically generated answers to local storage, which are presented in a rich html page through a Webview.
Some users have asked for the ability to export that file for safekeeping. I want to implement one javascript solution which works in either IOS or Android. So I need a solution that doesn't depend on a local file system (because IOS won't allow that).
I thought about creating an email a user can send to themselves. I could generate a pdf with one of the pdf libraries, but RFC 2368 says I can't attach that as attachments are not allowed in the mailto URL scheme. I can't put html in the body of a mailto email either, RFC 2368 again.
The local storage data is butt-ugly: I don't want to send raw data or JSON strings to an end user, and while I could render a plain-text mailto body, I'd have to lose images and just lay out some very long URLs in plain text and cross fingers that the client will render them as links.
A webview browser page can't be saved.
So what am I missing? What's the single genius solution for taking a web page that exists in local storage and providing the user a way to store it locally on a computer or snag it from a server, regardless of the device or operating system of their phone or tablet?
I'm an iOS dev looking into some security aspects of a native iPhone app that loads local html pages into a UIWebView (that's the iOS class that give browsers functionality to a native app).
If the app loads a local html file and that file contains a link to an external html file then is it possible for that external file to download a file to the client (another html file or a javascript file)? My knowledge of html/javascript isn't detailed enough in this area.
E.g. If A.html is file physically present on the phone and A.html contains a href to B.html where B.html is on a server then is it possible for B.html (using whatever means) to move a file (C.html or D.js etc.) from the server onto the device?
What you probably mean is : are HTML pages able to download (and potentially execute or overwrite) content/code on the device? I'm just going to assume that in the following.
First, the browser isn't supposed to be able to download anything without the user consent. That's especially true on iOS, where the browser actually can't download anything at all. (Well, you can actually download images by long-pressing on them, but they are only going to go to the Photo Roll. Any other download will just fail.)
HTML pages (and JavaScript, images, ...) are of course downloaded to the device before the browser or UIWebView displays them, but they can't access anything on the filesystem.
What's more, due to the same-origin policy, a web page cannot access anything that's outside of its domain (cross-origin requests allow this, but they require the server to send a particular header).
Say your page is on http://mywebsite.com : you can't make a request to http://blah.org if it's not setup properly, or even (much more dangerous) to file:///etc/passwd (which you have no way to setup properly).
I'm not sure about local pages, but (at least on Chrome on the desktop) local web pages cannot download anything at all.
Of course, all of these are the expected behavior.
There have been cases of vulnerabilities (this one for instance) where Safari allows unprivileged access to the filesystem, but in most cases they have been patched quickly by Apple and you won't have to (and are not supposed to if you want to avoid unnecessary headaches) worry about them.
As I have read, it is not easy for JavaScript to modify files on client PC. I am working on a web based file manager and would need to know the following:
Can JavaScript list files and folder structure on a client PC?
Can JavaScript list files and folder structure on a server?
If your answer is no, that Java Scipt can not list files and folders say on client's or server's C:\ drive, than would CGI script be the only solution?
Browser JS reading client PC's files: Depends
For a security reason, you can't access the files on the user's PC without the user's consent.
That's why the FileReader API is created around the file input box <input type="file"> and a drag-n-drop area since the whole idea is to "access the file with user's consent". Without the user intentionally putting the file for access, you can't access it at all.
Server-side JS reading own server's files: Yes
As for server, if you meant access the server using server-JS (NodeJS or Rhino), yes you can (How else would it serve webpages anyway?).
Browser JS reading own server's files: Depends
Accessing the server from the browser using JS works if you have an API to read files from it.
Browser JS reading other server's files: Yes, with a catch
To access other server's files without some API, you could resort to creating a web scraper or a web-spider that runs server-side (since browser can't cross domains due to the same origin policy) and have an API exposed to your browser.
However:
you can't crawl to all files as some may be restricted from outside access.
the public appearance of the structure could be different from the internal structure, especially if the site uses segmented url scheme
sites using query strings to generate pages cannot be crawled easily due to the number of permutations it could make, thus some pages might be unreacheable.
CGI won't be a solution either, as it only has access to the filesystem of your server, not that of the client visiting your site. The only way to access your client's filesystem from javascript seems to be the File API, which apparently is not implemented by many browsers.
It's a cludge but you could resort to a java applet or the dreaded active-x control.