mantrax3

Doesn't help if you click somewhere by accident and delete an email without noticing.

You can always shoot yourself in the foot even with a service layer.

But in a service layer you need to get it right once. And therefore if you don't, you have to fix it just once.

And coupling your business logic with your frontend layer suggests spaghetti code and violates DRY, because you typically have many frontends, but one app state.

Security is about focus. If the service coders can focus on the service being secure & fast, frontend guys can focus on the frontend being usable.

Otherwise you're asking everyone to think about everything, and human attention span, memory and skill sets are limited, and this does affect security.

If it's "not a hard problem" - and I agree it isn't, and it's solved by Clojure's SQL libraries, why should the web framework deal with it in any way?

And moving the problem actually helps, when the original place was the wrong place to solve the problem.

Security is one problem when you write queries all over the place. The other two problems are data integrity, and maintenance.

In a service layer you have exactly three concerns:

1) Validate abstract input (and permissions of the caller).

2) Perform the transaction.

3) Return abstract output (and/or errors).

No routers, no controllers, no views, no templates, no CSRF, no XSS, no HTML escaping, no GET, no POST, no nothing.

Just input, transaction, output. Pure data. Pure business logic.

And suddenly things that seemed hard to get right, or things you had to repeat all over the place in your code, get done simply, and just once. And all your web code calls the service layer.

All your iOS and Android app code - also calls the same service layer.

And they're both secure because you need to get the service secure just once - then all interfaces (web, mobile, desktop, API) use the same service.

And when you don't isolate the service, you'll be running SQL all over the place, and use every framework's souped up solutions to avoid SQLi.

Which one do you feel is better?

It's simple.

Let's see what the spectrum of PHP solutions is. It goes from:

- WordPress: very simple, you don't need to be a coder, not that powerful.

And goes until:

- PHP + libraries: complicated, you need to be a coder, extremely powerful.

And here's Drupal:

- Drupal: a lot more more complicated than WordPress, not that much less complicated than plain PHP, yet much less powerful than plain PHP.

In a nutshell, Drupal and apps like it want to be everything to everyone, and that's how bad apps happen.

WordPress may suck, but it has focus, and people with simple needs like the proposition.

Yes scores can't possibly be universal. But admit it. It just irks you to see a pop singer might be more popular than the president.

"But in our universe, people saw the algorithm as hackneyed, particularly when Justin Bieber had a higher Klout score than the US president."

Maybe Klout was wrong with this particular arrangement, or maybe your assumptions about who has more influence are wrong. Ever thought about that?

After all, "entertainment clout" can be very quickly capitalized as "political clout", as Mr. Terminator has demonstrated.

When it comes to selling products, whose endorsement will sell more products: Justin Bieber or the US President?

Remember Klout's score is used to give "perks" to influencers, the purpose of which is that they show those perks to their fans, therefore influencing them.

While I don't care about Klout at all, I have to say I'd rather bet on Justin Bieber than the US President for that specific purpose.

"That won't necessarily stop $developer making a little PHP interface long after you leave, which exposes your DB again."

Let me ask, does this hypothetical company have someone in charge of architecture, or everyone just codes randomly entirely on their own with no rhyme or reason until it works? Because that's what you're describing. Anarchy & chaos, with no one in charge.

The answer to the above hypothetical situation is that the PHP developer will code to the service layer, not to the database. In fact, that precise setup is very common in the projects I do: services (say in Java) consumed by delivery mechanisms (say PHP web sites).

Multiple independent apps reaching into the database directly is not only recipe for a security disaster, but a recipe for data integrity and maintenance disaster.

Here I explained service layers, so I won't repeat myself: https://news.ycombinator.com/item?id=7476725

In a nutshell, social engineering can be countered by proper software & processes engineering.

So if social engineering is possible, blame the software architects.

Maybe in extreme cases changing the email of an account might be needed, but there's no excuse a first level rep was able to do it. Least thing, he/she should've been forced by the system to escalate to someone above her, who has a much lesser chance to screw up.

Your logic is a bit weird.

Sendgrid just experienced this major embarrassment and are currently re-training their staff to avoid it again at all costs.

And you're going to move away from them now?

That's probably the one part that really didn't make sense. But maybe he did it for sport.

"and it looks inspired by PHP."

You're getting the order wrong here.

- It was inspired by Java.

- PHP OOP was also inspired by Java.

It's hard to argue that Java's OOP model is bad. It encourages clear code structure and works especially well for large project (for tiny projects you don't need OOP at all, anyway). This is why C#, PHP, this library and many more are based on Java.

Oh, BTW, let's keep digging:

- Java's OOP was inspired by Objective C.

- Objective C was inspired by SmallTalk.

It's always Lisp or SmallTalk, isn't that fun?

And a bunch of people coming out of their caves to tell us how JavaScript's quickly cobbled up hacky prototype system is a design by God himself, and everything else is the Devil trying to trick us into his Java ways... Sigh.

Which is why the next versions of JS (ES6 and ES7) will have:

1) Modules (namespaces)

2) Classes

3) Member visibility

Whoops. Ignore the cognitive dissonance and continue with the flame!

Now. While the library linked here isn't the prettiest thing I've seen, I immediately get it. And I can immediately start coding in it and get the expected behavior.

This, in itself, is a huge feature compared to the awkward incantations one has to do in barebones JS to do OOP (of any kind). Even the fact it's string based doesn't make it inferior to some of the other unreadable stuff I've seen by people doing JavaScript "properly" (or so they think).

So, I say kudos about that. Here we have an implementation solving a practical problem in a practical way. No plot twists and surprises.

I prefer TypeScript, but this one doesn't require a parser, so it has its benefits.

You may have heard about spreadsheets or relational databases...

Of course, and in software development we call these instruments, interfaces and well designed automated tools libraries.

A framework in aerospace would be more akin to a pre-built airplane with a bunch of holes where you put seats, in-flight entertainment consoles and other auxiliary non-critical equipment (because remember, airplanes are scary and you were told you can't do it yourself). Then you paint it and stick your logo on it.

Which is all fine, if it does the job for you, but you're not designing the airplane, anymore than microwaving TV lunch is you cooking. And just like warming up TV lunch doesn't make your job title a "chef", I don't believe people relying on frameworks to do the hard thinking for them deserve the title "architect" or even "senior developer". Which, again, is all fine, unless you or your boss are kidding yourselves about it.

And then one day the military, say, realize they now have a bunch of useless "military jets" built on top of a "passenger airplane framework". And NASA's space mission based on that framework isn't going too well, either. Whoops. Turns out frameworks aren't one-size-fits-all.

In a nutshell, apps have to be architected by competent architects, using simple, modular, does-one-thing-well libraries. These people know how to achieve scalability and security taking the particular needs of the app at hand.

The presenter in that video said that making assumptions is dangerous. There's no greater assumption than the fact a framework is right for your app, without understanding what this framework does under the hood. And there's no type of component making more assumptions for your app than a framework. Rails calls it "opinionated". I call it: you're the framework's slave, not the other way around.

There's no way around it. I know when Rails came out the hype was so huge, that everyone believed they and their dog can write big complex web apps. Nope. The only result of the framework mentality is a bunch of people making beginner mistakes and getting hacked all over the web.

It is always possible. Name one case where it isn't, and I'll tell you how it's possible :)

Web frameworks should handle input (routing, request fields, url query) and output (templates). That's it.

That private API is called a service layer, and without it, your code devolves into copy/paste spaghetti.

We live in an age when having a complementary iOS/Android app for your site is not the exception anymore. Without a service layer you'll have coupled your services with your web pages. Connecting your server with your apps will be quite painful. You don't want that.

Done right, your service layers keeps your code simple, secure, and easy to debug, even if it's web-only. I'd argue that anything else is just due to lack of experience.

A service layer also makes the work on a project more parallelizable in terms of number of developers that can work together on it, each focusing on their part of the puzzle, without breaking each other's code all the time.

Once again there's no way to make a mistake with a prepared statement. The only way to do it is using poor practices like using half baked "sanitizing" functions which no competent developer will use.

And once again, you don't need HMAC to store salt outside the hash. You just don't. HMAC doesn't dictate where you store your salt. You're bundling these two things together as if they're inseparable, but they're two completely separate things.

Well first of all your "common scenario" terrifies me, and betrays an app developed by incompetent devs who wouldn't even know what a "hash" is, because in any sane situation:

1) The SQL database is not public (any more than it's common to have public anonymous FTP to your server's app deployment). It listens on a specific interface, specific port, from specific IPs with a specific user and password (which is not "root"/"").

2) Input isn't properly sanitized? Hello? If that's "common" then fix that first. It's not 1998 anymore, no one has an excuse for that level of ignorance. First of all "sanitize" is an incorrect term for what needs to be done. You either escape an SQL literal, or you pass it as a parameter to a prepared statement. You do this to all data, all DB layers provide escaping, and it's absolutely trivial to do. And for prepared statements, there is no way to do it wrong, because it's not you who does it. Data and query in prepared statements are separated at the protocol itself and injection is impossible, you can't possibly mess it up. All of this is "using databases 101". Heck, your app will break even with innocent data containing, say, a quote, if you fail those.

3) I mentioned twice already, there's public salt for hashing the password, and there's irreducibly slow hash to be used to protect against a weak password (like Blowfish). This is what breaks brute-force attacks, not HMAC.

4) Let's assume your exact scenario is indeed terrifyingly common. Still, HMAC does nothing at all here, that keeping part of the salt off-the-DB won't do. HMAC doesn't mean "when you have a key outside the DB". You don't need HMAC to keep part of the salt outside the DB. Just... keep part of the salt outside the DB, without HMAC.

But if you feel the need to obfuscate your code like this, it means you're working in hell and some people don't deserve their jobs, and better fix that, before you start thinking about compensating for it at the wrong place of the app.

Nothing is secure by default, even Django and Rails. You can always shoot yourself in the foot, if you don't know the basics about security.

This is why the solution isn't relying on your framework, but on your competence.

SQL injection is not a problem of web frameworks, because SQL should never be a part of the web layer of an application in the first place.

The problem of lookup table attacks is solved by the public salt I already mentioned. HMAC protects against attacks like length extension (google it), which aren't applicable for discovering a password from a hash.

Encryption also does nothing here, because it's reversible.

Your encryption key is somewhere on your server, so whatever you encrypted (either the plain text password, or the hash) can be decrypted once, and then if it's a hash you just attack the bare hash as usual (brute force, dictionary etc.).

Instead of encryption you can just store part of the salt outside the DB, but with a good hash this is usually not needed and just pointless obfuscation.

"This is a standard developer response - I recall when Sinatra was a fresh kid on the block, and the same arguments people used against Rails"

And the more time passes, the more problems with Rails are being discovered that have to be altered in a non-BC way.

A library makes no assumptions. It's just there and you decide how to use it. In the right hands it's more powerful than a rigid framework.

A framework that tries to teach you how to do things is by definition a pair of training wheels. Not the best setup for competing in Tour De France.

The solution to incompetent developers isn't a bigger, more rigid framework. It's education and training.

Many things said in that video are kinda off.

He mixes password hashes and MAC (message authentication codes), saying we should HMAC our password hashes. There's little to gain from that:

- Password hashes exist to hide passwords. The attack is to discover the original password by brute force, dictionary, rainbow tables etc. The protection against this is irreducibly slow hash algorithms and unique public salt per hash.

- MAC exists to authenticate message origin. Unlike passwords, the message is often public. The attack is therefore not to discover the message, but to manipulate the message, yet make it appear from the same origin as the original message. The protection against this is the HMAC algorithm with a secret key that only the original message author has.

HMAC-ing your password hash won't stop, or even significantly slow down any of the attacks performed against password hashes, so it feels cargo cultish to claim it's just magically more secure by using it. It's even more WTF-y to claim a password hash library should offer HMAC, or it's insecure.

Once a system is compromised, and the attacker doesn't care to recover the original password, it's far more trivial to just replace the hash or just directly read the data protected by the login directly in the DB, rather than play out a MAC attack on a pass hash. It makes no sense.

HTML escaping. You either escape for HTML or you don't. There's no sane way to escape some of it. His idea that we should be able to escape some tags, but skip (or "strip") others is a huge vector of attack as HTML is notoriously filled with edge cases that your selective escaping/stripping engine won't have. It's not trivial to parse what's a tag and what isn't a tag to a browser, trust me. It only looks trivial if you're ignorant.

If you want to allow some tags, and disable others (say, allow bold/italic on forums, but nothing else) you should go through a strict DSL allowing only those types of formatting, which are then converted to HTML. Just like HackerNews does it - I type star-word-star and I get "word" in italic. That's a DSL. That DSL could be made to look like HTML, but it won't be HTML. It's fully parsed and rebuilt from the DSL syntax tree. So it can be made safe. Selective HTML escaping without those crucial steps is almost impossible to make safe by comparison.

His rant about "there are too many templating engines - we should stop" - yeah, good luck saying we should stop and this working out.

Likewise about databases. "Let's just stop". B.S. The thing he's missing is that different DB engines have different strengths and weaknesses. That's one major reason there are so many, and why many get used in the same project. PgSQL isn't SQLite isn't MongoDB isn't Redis.

By enforcing one type of database for multiple separate project components, you don't improve security, you just cripple architecture and performance.

For CSV forbidding commas in data is not practical.

For ASCII delimiters, forbidding ASCII delimiters in data is practical.

Sure - you can't, say, nest ASCII tables into one another due to this limitation.

But for simple structure, it doesn't hurt to have ASCII separators in the toolbox.

The only big problem I see is that they're rendered as invisible characters, which will make debugging harder. If we wouldn't have abandoned and forgotten the special ASCII chars, this wouldn't be the case.

If your dev tools show special chars (like mine do), then it's perfectly fine to use them.

1) You were wondering why people disable JS.

2) You were making "THIS FACE" at one of them.

3) You didn't ask him why did he disable JS.

4) You're about to remake your site based on conclusions drawn by a sample of one.

Well, god damn it dude. That's not how thinking works!

Hey I like how they've blurred this DKJX3-7KBW5-237BT-K22TX-6XG7J key here in Chapter 5:

https://zapier.cachefly.net/static/CplbOk/images/learn/apis/...

... beyond any recognition!

I'm curious why they never make CRTs and floppies anymore. Let's write an article about it.

I find this particular form of cynicism entertaining. But this is not about the particular number of users lost.

It's about Facebook's brand.

There are many things Facebook might want to do, but it can't, because people don't trust them, and their every movie is a potential cause for outrage.

No company wants to be left with the only alternative of buying their way into success, and as you see this doesn't work quite smooth, either.

I know women, programmers, who are in love with programming. Hell they're more in love with programming even maybe than I am. We have wonderful arguments about SOLID, and CQRS and event-sourcing and queues, and pipes, and job servers.

Loving your job isn't exclusive to men.

Anti-sexism is reaching a different type of extreme, where certainly we should be hiring women who don't love their job, just so we're not sexist?

I know where to draw the line. And I'm drawing it before that.

Facebook buys WhatsApp - hundreds of thousands creeped out, go to Telegram app.

Facebook buys Oculus Rift, Minecraft creator cancels talks, creeped out.

Feels like that Facebook brand has taken a hit or two with all the privacy violations, huh?