Does a mobile application written with Nativescript, which utilizes a cross-platform Javascript runtime, have the same XSS vulnerability as a website?
Well, in the strictest sense of the definition of XSS, no. However security vulnerabilities in general -- I guess that depends on several factors about your application. In the strictest sense a normal app the answer would be no; because in a normal application it is not written to download or run any external or user code. So since you don't download or run any external code; that eliminates that risk.
So in a normal application; no. However, if you make some app that actually allows a third-person to run there own JS inside your app; then yes by running any JS you open up the opportunity to compromise your app. But that really wouldn't be XSS, it would just be a security vulnerability you created as you are allowing others to run code in your app. (This is the same with ANY environment, the minute you allow someone to run code in your app; you open the doors for all sorts of mischief)
Now if this "extra" code is downloadable from a website; then you could get a XSS like issue where "BadGuy" posts a JS file on your website and then while extolling the virtues of how cool his script is, "NaiveGuy" downloads and runs it. Bam, NaiveGuy has his phone compromised by a script that you have on your website... But again this is something you would HAVE to specifically make this type of system to allow this to occur; this is not an issue built into NativeScript...
Two notes;
Any platform can suffer from this issue; NativeScript, React Native, Ionic, Cordova, WebSites, Node, Java, C, etc -- you allow a BadGuy to run code inside your app; you are in deep trouble security wise...
If you are using a WebView component in your NativeScript App (or any other language), then the WebView component itself can have XSS issues totally unrelated to NativeScript based on the website have it go to, as the WebView is a true Web browser component and it will do exactly what Chrome or Firefox would do on the site... But any XSS issues in the WebView caused by the website doesn't correlate to an issue inside NativeScript as the WebView is isolated from NativeScript...
Related
I'm entering the world of Shiny Rstudio now. So this is a beginner question
One question I came up with is: how do I search for the Shiny Apps available/created? Are all created Apps available? Is there any way that, once I create my app, I prevent it from being viewed? Or during the creation I "block it"?
From so much searching I found this link via Rstudio's website: http://www.showmeshiny.com/
Would this be the search platform for all apps made?
But in the case of http://www.showmeshiny.com/ it seems that it is necessary to send it via "Submit App".
I am not sure if I understand your questions correctly but I might be able to give you some insights.
Are all created Apps available?
No, some shiny Apps are hosted on private servers or/and are embedded in password-protected websites or Wordpress-pages for example. If you dont have those access rights, then you cannot see those Apps.
How do I search for the Shiny Apps available/created?
There is no way of doing that, except on pages like Showmeshiny, the RStudio Shiny Gallery, this gallery of recent Shiny-Apps or pther similar pages. Those Apps are publicly available and you can submit your own App if you like sharing it. Shinyapps.io is a nice and easy way of deploying your App on a server with a few clicks. But you need at least the standard license to include authentication, otherwise they would be free and open for everyone.
Is there any way that, once I create my app, I prevent it from being
viewed?
I am not quite sure, what you mean. If it should be blocked from being viewed at all, I dont see the reason of building a ShinyApp. If you just want to access it yourself, then there are ways of doing so. Either password-protect it where only you know the password or host it on a local server that only you can access.
Or during the creation I "block it"?
If you create it on your computer and run it, it will run on your computer and only be accessible to yourself, except you explicitly configure it otherwise. So there is no need of "blocking it".
I've designed a desktop app using PyQt GUI toolkit and now I need to embed this app on my Django website. Do I need to clone it using django's own logic or is there a way to get it up on website using some interface. Coz I need this to work on my website same way it works as desktop. Do I need to find out packages in django to remake it over the web or is there way to simplify the task?
Please help.
I'm not aware of any libraries to port a PyQT desktop app to a django webapp. Django certainly does nothing to enable this one way or another. I think, you'll find that you have to rewrite it for the web. Django is a great framework and depending on the complexity of your app, it might not be too difficult. If you haven't done much with web development, there is a lot to learn!
If it seemed like common sense to you that you should be able to run a desktop app as a webapp, consider this:
Almost all web communication that you likely encounter is done via HTTP. HTTP is a protocol for passing data between servers and clients (often, browsers). What this means is that any communication that takes place must be resolved into discrete chunks. Consider an example flow:
You go to google in your browser.
Your browser then hits a DNS server (or cache) that resolves the name google.com to some IP address.
Cool, now your browser makes a request to that IP address and says "get me some stuff".
Google decides to send you back a minimal amount of HTML and lots of minified JavaScript in the page.
Your browser realizes that there are some image links in the HTML and so it makes additional requests to google to get each of the images so that it can display them.
Now all the content is loaded on your browser so it starts to execute the JavaScript code, and that code needs some more data from google so it starts sending requests to google too.
This is just a small example of how fundamentally different a web application operates than how a desktop application does. On a desktop app you have the added convenience that any operation doesn't need to be "packaged up" and sent, then have an action taken, etc (unless you're using a messaging architecture, but that's relatively uncommon outside of enterprise apps).
What is difference between a Desktop application and a Web development application? What is Testing Strategy for a web site/web application?
I will briefly share some of my experiences, as they may help establish a foundation for you.
The main differences that I have encountered are obviously the usage of markup languages (HTML/HTML5/XML, etc), AJAX, jQuery, and javascript (well, scripting in general). Tools like .NET framework amongst others also exist. You can look those up to get a full definition of what they are and how they work together, but they introduce a new way of problem solving in terms of building small bridges to reach the end result.
As in any application, keep in mind the user-end side of the application. Millions of people will have access to it at exactly the same time. Security is paramount with web apps. Ensure you have strong security measures tied into your page.
Aesthetics will take more precedence than with desk applications (depending on what they are). Web applications are a visual experience. You want to make sure that when you design it, fields are easily identifiable, the app is easy navigable, and easy to read.
For testing, simply save your code with the right extension and run it from wherever you saved it. Most current Op Systems know what kind of web code the file is written in and will open it in a browser. Say if you wrote "myPage.html" and saved it to your desktop, you will see an HTML icon that says "myPage". If you need to make changes, edit your code, re-save it, then simply refresh your web browser.
I know this is a very very general answer but I'm attempting to brush upon everything that I've experienced over the summer. Hopefully this is helpful, or atleast brings some considerations to mind when designing your web app. Good luck!
When try to run dijit tests from 1.7 version, popup window shows up and test will not progress any further.
Popup says:
DOH has detected that the current web page is attempting to access DOH, but belongs to a different domain than the one you agreed to let DOH automate. If you did not intend to start a new DOH test by visiting this Web page, press Cancel now and leave the Web page
Clicking OK or Cancel doesn't do anything.
Whats going on a how to fix this?
Browser is Firefox 9, java is working (at least test page say so).
It's slightly hard to tell what the problem is, as you've not said whether you're running this from a local filesystem or under a web server, or which URL you're using.
I've had various problems trying to get DOH Robot running from the local filesystem, but good success running them under a web server.
Try it under a web server (any type will do), and try visiting the URL
http://server:port/ROOTDIR/util/doh/runner.html?testModule=dijit.tests.form.module
(where http://server:port/ROOTDIR/ points to the top of your Dojo SDK directory)
That works fine for me with Dojo SDK 1.7.2; sometimes I then get the same prompt you get, but OK enables the test to continue happily.
If that doesn't work, see if you can run a test page directly without the DOH browser runner wrapped around it, e.g.
http://server:port/ROOTDIR/dijit/tests/form/robot/Button_mouse.html
That might prove easier to diagnose.
This is not a question about writing a web-app Vs a desktop app. It's a question about allowing a bespoke application to run in a browser though use of a custom plugin, effectively using the browser just as your render-window.
QuakeLive does this - it's a C++ application with some extra code to run through a browser. Unity3D and Torque game engines also provide deployment options to do the same thing.
Personally, I'm a bit dubious about the usefulness of such a system. But I'd welcome other opinions on the reasons why this might or might not be a good idea.
Not sure if there's a proper term for this, please edit my tags if there is!
It depends on the application. My background is in medical imaging, but what I have to say would apply to many information system clients:
Pros:
it gets easier to build REST-based integrations between applications. This type of integrations can be used by admins to build integrated portals. (So case ID's from one application can be used to launch another with the right context etc).
ideally, users can install your application themselves, on-demand (depends on context if this is really possible)
Deployment of new versions gets easier. Usually the hosting technology has deployment built-in. In client server environments, this can save a lot of work for the IT department.
You can have a single start URL for PC's and thin web clients (like phones). This makes it easy for users to find your application.
You can centralize configuration for clients. For standalone clients, you could of course centralize configuration somehow, but if you app is web based, you always know for sure there is a server, so you can always use it.
you can offload work that's ineficcient to do locally to the server. (reduce # of roundtrips between client/server).
Cons:
Each browser vendor has its own model of wrapping the native code. There are not too many, but it's definetly extra work.
Your app has to "play nice" with the hosting application. Like when the user closes the browser window, the browser may have prescribed when and how you can ask the user to save.
updates to browsers can break your plugin.
system admins may have restricted installation of plugins, disallowing users to install your application on demand (this happens a lot for activex).
your users may not like that extra code is injected into the browser (there is a lot of malware around that does this)
you don't have the opportunity to update prerequisites before installation
I don't believe really that it's just wrapping existing code in a plugin framework.
Your application won't work anymore when the server is down...