It’s time to kill the web app • Hacker News Board

Re: It’s time to kill the web app

#661

Post by romanixromanix » Sun, Sep 24, 2017, 8:06 PM UTC

During the last 20 years I used to prefer web apps over native (C++, Java, C#) for banking and trading applications. (although most developers didn't like to fight browser incompatibilities).

2 years ago I changed my opinion. We've developed two different user interfaces for trading at the same time. One with HTML5, Typescript, Angular, WebSockets, and the other one with JavaFX. The developement of the JavaFX based application was way cheaper, faster, pleased users more (due to multi-window!) and had by an order of magnitude fewer glitches in the UI. (But the web application was prettier).

Re: It’s time to kill the web app

#662

Post by sah2ed » Sun, Sep 24, 2017, 8:58 PM UTC

TeMPOraL wrote: post #522

naasking wrote: post #465

Earlier quoted context omitted.

> A programmer thinks of all the ways that a program could fuck up your computer; it's a large part of our job description. The average person is terrible at envisioning things that don't exist or contemplating the consequences of hypotheticals that haven't happened. I'm not sure programmers are much better. There's a long history of security vulnerabilities being reinvented over and over. Like CSRF is simply an inst…

> And blaming this on the market is a cheap attempt to dodge responsibility. If programmers paid more than lip service to responsibility, they'd push for safer languages. If programmers paid more than lip service to responsibility, the whole dumb paradigm of "worse is better" would not exist in the first place. As it is, we let the market decide, and we even indoctrinate young engineers into thinking that business ne…

> If programmers paid more than lip service to responsibility, the whole dumb paradigm of "worse is better" would not exist in the first place.

I used to think like this but I've come to realize that there are two underlying tensions at play:

- How you think the world should work; - How the world really works.

It turns out that good technical people tend to dwell a lot on the first line of thinking.

Good sales/marketing types on the other hand (are trained to) dwell on the second line of thinking and they exploit this understanding to sell stuff. Their contributions in a company, in general, are easier to measure relative an engineer since revenue can be directly attributed to specific sales effort.

"Worse is better" is really just a pithy quote on how the world works and it's acceptance is crucial to building a viable business. Make of that what you will.

Re: It’s time to kill the web app

#663

Post by mike_hearn » Sun, Sep 24, 2017, 9:08 PM UTC

bastawhiz wrote: post #651

mike_hearn wrote: post #597

Earlier quoted context omitted.

The prevalence of XSS suggest that the web ecosystem has failed to produce the sort of tools you suggest. If such tools actually existed and were good, people would use them and web app exploits would be a curiosity rather than an expectation. However, no such tool exists. I think there's a deeper issue here: the sheer number of ways you can generate XSS alone, even ignoring the other exploit types, is far beyond wha…

> If such tools actually existed and were good, people would use them and web app exploits would be a curiosity rather than an expectation. I think you're missing another two obvious explanations: 1. Lack of education when picking a tool (copy paste from bad SO answers is a frequent source of bad code). 2. Developers don't care. If it works, why bother wrapping your head the rest of the way around to understand why i…

I think it's easy to blame developers for the failings of their tools and just say, well, they should be more educated or more serious. That'd be great, but there are too many problems with the web to educate users on how to avoid them. Even skilled developers can't reliably avoid every minefield. Look at the attacks by Homokov that I linked to, or read up on HEIST, or cross site tracing, or SSRF attacks.

How many developers do you think might have written a web server in their time, or will do in the next 10 years? And how many know will pass URL components straight through to glibc for resolution, as is the obvious way to do it, and create an exploitable SSRF vuln on their network? How many developers will have even heard of this type of problem?

New ways to exploit weird edge cases and obscure frameworks crop up constantly - it is a full time job even to keep up with it all. At some point you can't blame people walking through a minefield because they keep getting blown up. The problem is the mines.

this issue could happen with any other non-web system, turning into any other kind of vulnerability. This isn't a web problem, it's a system security problem.

That's just not the case, sorry. Have you ever actually written desktop apps that use binary protocols? It's a web problem:

• It relies on the over-complex and loose parsing rules for URLs

• It relies on unexpected behaviour in one of the most popular web libraries

• It relies on bizarre and unexpected behaviour in XmlHttpRequests

• It relies on the fact that web apps routinely import code from third party servers to run in their own security context.

I have been programming for 25 years and I have never seen an exploit like that before in managed desktop apps using binary protocols to a backend.

Seriously, try to accidentally have a XSS vulnerability in an isorendered React app with Apollo.

An isorendered React app with Apollo? I think that may be the most web thing I've heard all week ;)

I think I'll take the bet:

https://medium.com/node-security/the-most-common-xss-vulnera...

That article shows the patterns I cover in my article:

• Buffers can get terminated early, even in a theoretically "XSS-proof" framework.

• JSON can get interpreted as code

• Even experienced web developers can't get it right

If you've never written a desktop app before, I'd suggest grabbing IntelliJ or NetBeans and trying it out. TornadoFX is a good framework to try.

Re: It’s time to kill the web app

#664

Post by mike_hearn » Sun, Sep 24, 2017, 9:15 PM UTC

51stpage wrote: post #324

mbreese wrote: post #194

Earlier quoted context omitted.

I'm having a hard time seeing how having separate control and data streams would have an effect here. Using FTP to retrieve a document isn't more secure than HTTP... the problem is in how the document itself is parsed. If you added a separate side channel for requesting data (a la FTP), you'd still have the issue of parsing the HTML on the other side. Granted, if you made that control channel stateful, you'd make a l…

SQL injection attacks are an excellent example where code and data are mixed. One solution is to do a lot of clever escaping of 'attackable' characters that instruct the DBMS to stop treating a character string as data and start executing things [1]. Escaping attackable characters attempts to partition data from code. This usually works but not perfectly. Or, run your data through stored procedures instead. It took m…

I think you mean parameterised queries. Stored procedures are a slightly different thing.

Re: It’s time to kill the web app

#665

Post by majewsky » Sun, Sep 24, 2017, 10:26 PM UTC

yorwba wrote: post #584

nostrademons wrote: post #312

Earlier quoted context omitted.

You run up against Gall's Law [1]. The root cause is that many of our desires are actually contradictory, but because human attention is a tiny sliver of human experience, whenever we focus our attention on some aspect of the system we can always find something that, taken in isolation, can be improved. (I'd be really disappointed if we couldn't, actually; it'd mean we could never make progress). However, the "taken…

> Move to a binary protocol and you can't do "view source" or open a saved HTML file in a text editor to learn what the author did I disagree with that. Using binary formats to exchange data between programs doesn't preclude using textual formats at the human/machine boundary. Yes, "view source" needs to be more intelligent than just displaying raw bytes, but that is already the case with today's textual formats. Eve…

> the browser dev tools already have to include a "prettify" option. Moving to a binary protocol would turn that into "decompile" and make it mandatory, but it effectively already is.

This will be a legal problem. At least in my jurisdiction, transforming source code (which is what prettifying is) is not subject to legal restrictions, but decompiling binary machine code into readable source code is forbidden by copyright law. (For the same reason, I'm concerned about WASM.)

Re: It’s time to kill the web app

#666

Post by majewsky » Sun, Sep 24, 2017, 10:36 PM UTC

scarface74 wrote: post #631

51stpage wrote: post #324

Earlier quoted context omitted.

SQL injection attacks are an excellent example where code and data are mixed. One solution is to do a lot of clever escaping of 'attackable' characters that instruct the DBMS to stop treating a character string as data and start executing things [1]. Escaping attackable characters attempts to partition data from code. This usually works but not perfectly. Or, run your data through stored procedures instead. It took m…

Stored procedures are bad in so many ways - they harder to deploy and revert than code, harder to unit test* , harder to refactor and every implementation that I have ever seen that has business logic in stored procedures instead of microservices/packages/modules have been a nightmare to maintain. * At least with .Net/Entity Framework/Linq you mock out your dbcontext and test your queries with an in memory List https…

> harder to deploy and revert than code

Agree.

> harder to unit test

Disagree. I've implemented unit tests that connect to the normal staging instance of our database, clone the relevant parts of the schema into a throw-away namespace as temporary tables, and run the tests in that fresh namespace. About 100 lines of Perl.

That was five years ago. These days, it's even easier to do this correctly since containers allow you to quickly spin up a fresh Postgres etc. in the unit test runner.

Re: It’s time to kill the web app

#667

Post by wcr3 » Sun, Sep 24, 2017, 10:44 PM UTC

heavy on vitriol, light on substance. fun to read if you don't ask questions.

Re: It’s time to kill the web app

#668

Post by collinmanderson » Mon, Sep 25, 2017, 1:03 AM UTC

I'm surprised no one has mentioned same-site cookies. This would help a lot with privacy and mostly solve BREACH, CRIME, HEIST, CSRF, mime-confusion, JSON issues, etc.

https://www.owasp.org/index.php/SameSite

It wouldn't solve XSS or SQL injection, but native apps are just as vulnerable to SQL injection as html5 apps, so I'm not sure why the author brings that up.

I'm curious what the author will propose as the solution.

Re: It’s time to kill the web app

#669

Post by erikpukinskis » Mon, Sep 25, 2017, 1:05 AM UTC

blub wrote: post #562

erikpukinskis wrote: post #295

Earlier quoted context omitted.

Are you comfortable running arbitrary binaries built by arbitrary people? If not, then I fail to see how an operating system is a sensible general purpose computing platform. It worked OK when we just wanted to run software written by a handful of trusted parties... Microsoft, Adobe, id Software. But as soon as there were 1000s of companies writing software that we wanted to try, running binaries ceased to be a good…

"But I will open basically anything in a web browser because I don't have to trust it." That's incredibly funny. I guess sooner or later you'll learn why it's a losing strategy. The web is probably the largest malware infection vector nowadays.

Instead of making fun of me, could you point me at a place to learn? What in-browser malware am I not aware of?

Re: It’s time to kill the web app

#670

Post by eli_gottlieb » Mon, Sep 25, 2017, 1:20 AM UTC

pjmlp wrote: post #578

artagnon wrote: post #311

Earlier quoted context omitted.

Every generation of programmers _does_ learn from previous work, and every new platform starts from scratch learning the lessons, and incrementally evolves. A Hello World GUI on Windows 95 will require calling into a complex and undecipherable Win32 API; a Hello World on the web needs one simple line. Platforms do get frozen over time (like the Linux kernel), and people use it to build useful things with low effort.…

Instead of doing console.alert("Hello World") We would do (VB) MsgBox("Hello World") Or maybe (Delphi) MessageBox("Hello World"); Only hard core C devs bothered to use Win32 directly.

Look, if we start comparing today's way of writing end-user applications to Delphi we're just going to sit here crying all the time. It was a beauty and a blessing, and I've never seen any way to develop GUI applications surpass the Delphi Visual Component Library.

Once upon a time, this was a solved problem.