| View previous topic :: View next topic |
| Author |
Message |
1clue
Advocate
Joined: 05 Feb 2006
Posts: 2569
|
 Posted: Fri Nov 30, 2018 8:10 pm Post subject: |
 |
|
| pjp wrote: | | ... Given these comments, is it possible to secure JavaScript (or any dynamic language)? |
If it were easy something would have been proposed and likely implemented already.
A few years back, JavaScript worked differently across browser vendors, operating systems and even versions of a browser on a single OS. It took them more than a decade to get a handle on just that.
It took Java awhile to get traction too, and the consensus was to abandon Java in a web browser entirely even though the signed code concept worked pretty well. The truth is that Java is too heavy for a browser, and the ways that it needs to interact with the client means it's difficult to secure just by the requirements. Over the years Java has gained consistency and security by leaps and bounds, but still has a distance to go for some types of applications. Some of that work (e.g. signed applications and libraries) has trickled into bare-metal operating systems and applications, and may possibly work for a dynamic scripted language like JavaScript, but there are qualifications.
First, the same use cases that caused Java to be so difficult to secure in a browser will also make JavaScript (or any other scripted language) difficult to secure, and their importance to functionality will be the same too. Some of the problem is the nature of the requirements.
Second, the fact of JS being an interpreted script where it's possible to put code into a variable and execute it adds its own complications.
Third, while tests can exist to pass or fail certain functionality in a JS implementation, and they DO exist, the truth is that each vendor will do something extra to make their implementation better. So there will likely continue to be a core set of standard features but there will absolutely be significant differences between one implementation and the next. It's the nature of the beast. It's also how browsers and languages and whatever else improve over time, so it's both a good thing and a bad thing. But the hard part of this is knowing how to secure those new features. |
|
| Back to top |
|
 |
1clue
Advocate
Joined: 05 Feb 2006
Posts: 2569
|
| Posted: Fri Nov 30, 2018 8:15 pm Post subject: |
|
|
I think it's indisputable that a universal client needs some sort of programmability for complex sites. I think it's also indisputable that many things could be done without programmability, without any loss of function or convenience.
I don't believe it's possible for a markup language like html to support enough functionality to satisfy the type of apps I build. It's not like what I do is so complicated, but what I do is significantly different from what the next guy, with a completely different type of app, is going to want. |
|
| Back to top |
|
|
jonathan183
Guru
Joined: 13 Dec 2011
Posts: 318
|
| Posted: Fri Nov 30, 2018 8:53 pm Post subject: |
|
|
The ability to use a simple browser such as Links in graphic mode is desirable, and for me preferred particularly for online banking activities. While I used to be able to do this with one of my banks I am no longer able to do so.
I'd trade convenience for security for most sites ... unfortunatley more and more sites seem to be moving away from the option of using a simple browser like links  |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Sat Dec 01, 2018 2:44 am Post subject: |
|
|
| 1clue wrote: | | If it were easy something would have been proposed and likely implemented already. |
Obviously :). Thanks for your detailed reply. I was mainly getting to the point of "hate." I think it is more about a lack of ability to secure an environment. Which as your comments point to, is not yet possible. The practice of relying on third party sites seems to be the worst offender. Next, for me, would be the ability for code to be injected into a site. And the third issue is with browsers themselves. Instead of being the most sandboxed and locked down piece of software, their creators seem intent on creating more holes (I only half-joking wonder if that is sponsored).
Unfortunately, all of the effort behind web apps seems horribly misplaced. I have yet to personally use a web based application I would call worth using. The internet ought to be more about data than presentation. It is so bad that I'd prefer plain text email, news groups and maybe gopher (never actually used the last one). I understand the economics of a single platform, but it really seems like a race to the bottom.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
1clue
Advocate
Joined: 05 Feb 2006
Posts: 2569
|
| Posted: Sat Dec 01, 2018 4:33 am Post subject: |
|
|
pjp,
Third party sites: The only thing I can think of is to have an advertiser spec out an ad, and then have the site's developers build the app. Or maybe have a certified development group do it, where the code is publicly reviewed and the developer is publicly rated for the quality and safety of their (open) code. This would have to go hand in hand with signatures on each piece of code/each ad.
Code injection can be dealt with, but at this point it's a small PITA for the developer, so it tends to not get done every single time. IMO this is something that can be addressed at the organizational level, with some sort of a unit test.
Browser security, that's a tough one. I suppose an uninvolved third party could rate all the browsers by a standard test harness and release the scores publicly? But each test would need to be wired into each version of the browser as changes happen, and some magical all-knowing test writer would need to be able to write tests for new features for that browser.
Webapps: They're the logical extension of CGI. Online banking, online shopping, surely something like Amazon or YouTube qualifies as worthy webapps. A video site could probably do without scripting if the HTML is consistent between browsers, but I submit that an online banking app without client-side code is probably not desirable. Webapps bring consistent security, better session management, better transactional integrity and a host of other things to the table that CGI always had trouble with, or that you had to struggle to keep straight as a developer.
I'm sure you know that. But my point is that if you accept the idea of functionality on a web site, then webapps are the best available tool.
I haven't seen any public webapps with the sort of information density that you see on a major accounting package. Some of the larger companies need to process millions of transactions per day, and some of the payments have thousands of line items. Maybe 80-95% of that can be handled automatically depending on the company, so there is still a relatively large group of humans who need to see each batch, each payment associated with it, and each line item associated with each check all at the same time so they can make sense of it. And it's not just one person working the data, it's dozens or hundreds, and they may not all be in the same country.
With different countries and branch offices having different requirements for hardware and network and whatever else, you can't rely on keeping every user on the same hardware, let alone the same updates. A webapp is the only feasible approach IMO. |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20067
|
| Posted: Sat Dec 01, 2018 7:19 am Post subject: |
|
|
| 1clue wrote: | pjp,
Third party sites: The only thing I can think of is to have an advertiser spec out an ad, and then have the site's developers build the app. Or maybe have a certified development group do it, where the code is publicly reviewed and the developer is publicly rated for the quality and safety of their (open) code. This would have to go hand in hand with signatures on each piece of code/each ad.
Code injection can be dealt with, but at this point it's a small PITA for the developer, so it tends to not get done every single time. IMO this is something that can be addressed at the organizational level, with some sort of a unit test.
Browser security, that's a tough one. I suppose an uninvolved third party could rate all the browsers by a standard test harness and release the scores publicly? But each test would need to be wired into each version of the browser as changes happen, and some magical all-knowing test writer would need to be able to write tests for new features for that browser. |
Does dealing with code injection in that way have a "name"? I'm curious to read more about it. But the main issue with all three of those scenarios (3rd party, injection, browsers), is that all of those solutions are not enforceable. Which effectively means no change from the status quo.
| 1clue wrote: | Webapps: They're the logical extension of CGI. Online banking, online shopping, surely something like Amazon or YouTube qualifies as worthy webapps. A video site could probably do without scripting if the HTML is consistent between browsers, but I submit that an online banking app without client-side code is probably not desirable. Webapps bring consistent security, better session management, better transactional integrity and a host of other things to the table that CGI always had trouble with, or that you had to struggle to keep straight as a developer.
I'm sure you know that. But my point is that if you accept the idea of functionality on a web site, then webapps are the best available tool.
I haven't seen any public webapps with the sort of information density that you see on a major accounting package. Some of the larger companies need to process millions of transactions per day, and some of the payments have thousands of line items. Maybe 80-95% of that can be handled automatically depending on the company, so there is still a relatively large group of humans who need to see each batch, each payment associated with it, and each line item associated with each check all at the same time so they can make sense of it. And it's not just one person working the data, it's dozens or hundreds, and they may not all be in the same country.
With different countries and branch offices having different requirements for hardware and network and whatever else, you can't rely on keeping every user on the same hardware, let alone the same updates. A webapp is the only feasible approach IMO. |
From a theoretical perspective, I agree that post-CGI web apps are "better." But not in practice. For Amazon, yes, because that's mostly the only option. For daily, "use it all day long" apps, absolutely not. They cause far more stress trying to get work done than they're worth (obviously business badger don't care).
I don't think either Amazon or Youtube are particularly good. They're usable in the sense that alternatives are non-existent or worse. To be fair to Amazon, I don't think the silver bullet has been found for shopping UIs. Selecting filters is fairly bad, particularly if it isn't in the short list of checkbox items. Then there's the issue of clicking those and applying to search terms already entered, or new searches negating selections, etc. A lot of that feels directly related to it being web based. And that says nothing about their Video service (although the Roku interface to Video was worse).
I no longer remember the original Youtube, but it seems like the main problem there is attempting to monetize it with autoplay, suggestions and other similar "improvements." I often find those approaches to interfere with basic use of the site (watching a video).
For denser apps, a good example (of how not to do it) is the VMWare client. One I'm glad I haven't seen if it exists yet is NetBackup. Their thick clients weren't great. But I can't for the life of me imagine how they could make a usable web version, particularly if they relied on the same designers. Other examples include the employee view of HR software. Just to manage time off and hours worked is a nightmare in the ones I've had to use. That my PII is stored in an internet accessible nightmare like that is horrifying. But there's nothing I can do about it.
Online banking? Most likely never again in my lifetime. I used it briefly, but the client side seems to have too much inherent risk. I just hope I'm not completely screwed in the event of their being hacked.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Sat Dec 01, 2018 1:06 pm Post subject: |
|
|
| pjp wrote: | | I just hope I'm not completely screwed in the event of their being hacked. |
If your account hold those 650 millions, i'm up to test your account security ; for free!
 |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Sat Dec 01, 2018 1:13 pm Post subject: |
|
|
| 1clue wrote: | | Third party sites: The only thing I can think of is to have an advertiser spec out an ad, and then have the site's developers build the app. |
You see many insecure javascript usage in all-in-one menu or similar tool, instead of adding the script itself within the website, a lot of devs are using the script directly from the original location.
With the "good" effect that when any bug is found and fix, the website need no update to get the fixes.
And the "bad" effect, if anyone hack the webiste holding the script: all websites that use it from the source are fucked up good.
Nobody would do an "ln -s http://kernel.og/libc.so.6 /lib64/libc.so.6" ; but that's what many websites do with javascript.
I think you have all seen this no? | Code: | m = s.getElementsByTagName(o)[0]; a.async = 1; a.src = g; m.parentNode.insertBefore(a, m)
})(window, document, 'script', '//www.google-analytics.com/analytics.js', 'ga'); |
|
|
| Back to top |
|
|
1clue
Advocate
Joined: 05 Feb 2006
Posts: 2569
|
| Posted: Sun Dec 02, 2018 6:22 am Post subject: |
|
|
| pjp wrote: | ... Does dealing with code injection in that way have a "name"? I'm curious to read more about it.
|
Not sure if there's a name for it, specifically. I would try to go about it the HTMLEncode way. It would likely be more difficult for code, but if you take all user input and transform it so that it cannot be JS, then that would at least reduce the attack surface right? I haven't seen anyone actually do this, but it seems to be a workable approach.
| Quote: |
But the main issue with all three of those scenarios (3rd party, injection, browsers), is that all of those solutions are not enforceable. Which effectively means no change from the status quo.
|
Absolutely correct. The same way that code signing is entirely optional, but works anyway. Or the little lock on the browser next to the URL box, saying that the site is in https and that the certificate is trusted. In my mind, the tasks are listed in order from easiest to hardest.
- The primary site (the one you went to) certifies that all content is written by 'trusted' sources who will put their name on it.
- The authors and site certify that all editable content is injection-proof by all known techniques.
- The browsers use only certified script engines and prevent known exploits.
Let me reiterate that the last item I have no idea how to go about, and that item number 2 is my personal ruminations on how to prevent injection by making everything "not script".
| Quote: | From a theoretical perspective, I agree that post-CGI web apps are "better." But not in practice. For Amazon, yes, because that's mostly the only option. For daily, "use it all day long" apps, absolutely not. They cause far more stress trying to get work done than they're worth (obviously business badger don't care).
|
You can't just push a button and everything is better. You have to start somewhere, try an idea and see if it makes an improvement. Then go on to something else.
| Quote: |
I don't think either Amazon or Youtube are particularly good. They're usable in the sense that alternatives are non-existent or worse. To be fair to Amazon, I don't think the silver bullet has been found for shopping UIs. Selecting filters is fairly bad, particularly if it isn't in the short list of checkbox items. Then there's the issue of clicking those and applying to search terms already entered, or new searches negating selections, etc. A lot of that feels directly related to it being web based. And that says nothing about their Video service (although the Roku interface to Video was worse).
|
Speaking from experience with some of the accounting packages that big businesses use, the people using the app likely have difficulty understanding and/or/xor/not or other logic, and complex logic would be even more difficult. We've tried that before, and the best we could get to was 'amount >= 1000.00' or 'dueDate < yesterday'. The people who call you to collect a debt or who apply money in big organizations likely don't have a degree at all, and may not have a diploma.
| Quote: |
I no longer remember the original Youtube, but it seems like the main problem there is attempting to monetize it with autoplay, suggestions and other similar "improvements." I often find those approaches to interfere with basic use of the site (watching a video).
|
I think you're right.
| Quote: |
For denser apps, a good example (of how not to do it) is the VMWare client. One I'm glad I haven't seen if it exists yet is NetBackup. Their thick clients weren't great. But I can't for the life of me imagine how they could make a usable web version, particularly if they relied on the same designers. Other examples include the employee view of HR software. Just to manage time off and hours worked is a nightmare in the ones I've had to use. That my PII is stored in an internet accessible nightmare like that is horrifying. But there's nothing I can do about it.
|
VMware client could largely be a webapp, but the virtual console is definitely not.
| Quote: |
Online banking? Most likely never again in my lifetime. I used it briefly, but the client side seems to have too much inherent risk. I just hope I'm not completely screwed in the event of their being hacked. |
I'm not listing things I'd recommend people use, I'm listing things that people use. Lots of people use online banking. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Networking & Security
