Harvesting credit card numbers and passwords from websites

Post by rmrfrmrf » Sun, Jan 07, 2018, 2:25 AM UTC

Silhouette wrote: post #33

dkersten wrote: post #9

Earlier quoted context omitted.

I was going to say the following: Except that being responsible for your dependencies (and the dependencies of your dependencies...) is impossibly hard. You would need to build everything yourself after auditing the code. But then I thought about it some more and its likely that you don’t need to audit the code, since the malware probably isn’t in the public git repo. Yes, its still a risk, but the probability of mal…

It's only impossibly hard to audit this kind of thing if you have an insanely large and deep tree of transitive dependencies in the first place. This seems to be a particularly bad problem in the JS world, for this and many other reasons, but most programming languages and their communities don't work that way. Auditing a small number of larger dependencies, when most of them are probably widely used and from reasona…

Post by rmrfrmrf » Sun, Jan 07, 2018, 2:34 AM UTC

mulmen wrote: post #54

z3t4 wrote: post #35

There is this trade-off between usability and security. For example being able to load data from other domains, now with origin policy we have do fetch the data server side. One nice thing about web apps is that they do not require a server to work. But due to xxs injections we cant have nice things.

It's almost like the browser is being abused to do something it fundamentally should not be doing. If you need to do that much client side heavy lifting maybe a web browser is not the place for it? The ship has probably sailed on that line of thinking but in my opinion a lot of the pain we experience in web security today comes from people trying to do things they really should not be doing.

Post by Gaelan » Sun, Jan 07, 2018, 3:59 AM UTC

jmadsen wrote: post #47

milesvp wrote: post #42

Earlier quoted context omitted.

What makes npm particularly bad, is that JS has such a teribad stdlib. When you need to write your own lpad() at some point its easier to include a stupid little package that has dealt with all the edge cases you don't want to care about. So you end up with way more third party deps than a kitchen sink type language. Otherwise, yes this is a fundamental dependency issue.

but that has nothing to do with npm. that's the same for any javascript package manager - yarn or bower would be the same.

Post by mulmen » Sun, Jan 07, 2018, 6:25 AM UTC

z3t4 wrote: post #76

mulmen wrote: post #54

Earlier quoted context omitted.

It's almost like the browser is being abused to do something it fundamentally should not be doing. If you need to do that much client side heavy lifting maybe a web browser is not the place for it? The ship has probably sailed on that line of thinking but in my opinion a lot of the pain we experience in web security today comes from people trying to do things they really should not be doing.

There's this vision for the web that we should be able to access public "data" , not only web sites "guarding" it.

Post by z3t4 » Sun, Jan 07, 2018, 8:29 AM UTC

mulmen wrote: post #88

rmrfrmrf wrote: post #83

Earlier quoted context omitted.

Good point. I’ll talk to some guys and we’ll turn off the World Wide Web tomorrow. Fun experiment but there were a few security bugs (fixable, but why spend the time?) and, most importantly, @mulmen didn’t like it too much.

That's really not my suggestion. If you need to write a full application why does it have to happen in a browser? Why can't we use the model so successfully employed on mobile devices?