That's awesome. We used OpenVPN because that's what we were familiar with, but your L2TP script looks great. Would you mind if we tried to integrated that at some point?
There are a number of ways: malware, browser extensions, man in the middling, etc. SQLi would have been a better example than XSS, but there are definitely ways in which XSS can still be harmful if thrown in a cookie. If you wanted a persistent XSS for example, you could use a reflected XSS to create a longer lasting XSS attack in someone's login cookie, causing that to be executed every time they hit the page rather than just the one time they click on a malicious link you sent them. Does this make more sense?
Malware, browser extensions, and MitM could all just inject the XSS payload into the page directly without having to go to the fuss. Why go through a cookie?
Reflecting the attack through the cookie makes sense if you can find an XSS-vulnerable page that you could use to deliver a payload that can be used to write a cookie to leapfrog the XSS attack to non-vulnerable pages, but that requires a pre-existing XSS attack and a vulnerable usage of cookie data; the simple ability to modify cookies isn't inherently a vulnerability.
If you can actually force malicious content into someone else's cookie, then absolutely, all bets are off. But the vector as described in the article seems to be entirely benign - just because someone can alter their cookies doesn't mean they can XSS other people.
No problem at all! We may very well start crawling your advisory DB for our own mailing list, which isn't limited to just Ruby, to be fair. ;)
It's always good to have more eyes on security issues - Ruby or not - and keeping the community informed. Feel free to get in touch with us at support@tinfoilsecurity.com - we'd love to chat about any ways we can work together.
This is an interesting take. For us, it's not about age, but about personality. We have a financial controller who is 20 years older than everyone else on the team and we'd bring her on full-time in a heartbeat if we needed a full-time controller. She has a great personality, is fun to have in-house, and knows what she's doing.
How I look at the Sunday test is less of a "are they like me" and more of a "will I get along with them many hours a day"? We work anywhere from 7 hours a day, up to 18 (especially during major code pushes) - we try to avoid this as much as we can, but sometimes (for us at our stage), it's inevitable.
I do have to enjoy working with my colleagues, and someone for whom I won't be willing to come in on a Sunday has a higher chance of bringing me down on a regular basis. That doesn't mean we work Sundays (we're typically in the office M-F), but it's important to be able to get along with people and it's a good litmus test, imho.
I'm not here to tell you to hire people you don't get along with. But you shouldn't regiment hiring rules that are based on things like "culture fit" or "getting along", because they code for subjectivity and culture bias.
You should certainly rule out people who are disagreeable, or who immediately send signals that they'll be logistically difficult to work with. But you should base those decisions on some kind of objective metric. That requires some up-front thought: what are core hours? Do we avoid meetings and thus require lots of continuous written feedback? Do people need to be comfortable with our chat system?
But as you think of those metrics, start to worry when you get to things like "will this person usually be available to review code prior to deployment on a Saturday night?".
I'm the opposite. I don't want to work with people who I "get along with". I want to work with people who will tell me I'm an idiot when I do something idiotic. I want someone who puts all their effort into creating great technology, not someone who puts all their effort into being liked. I have thick skin, so it doesn't bother me to work with an abrasive person.
That, of course, only applies to programmers. On the other hand, if I'm hiring a salesman, I'd want that person to be the kind of person who puts all their effort into being a likable person. The same goes for hiring managers. Being a likable person will get you far in many positions in a business. Programming is not one of them.
We all have thick skin at Tinfoil - we don't want to hire someone who is necessarily liked by everyone, or who won't tell us what is on his/her mind and be honest. We're incredibly transparent, and whether or not we like someone is certainly not the /only/ reason we would hire someone. Honesty and straightforwardness is a trait we value a lot.
'iamelgringo (who I miss!) is telling me that just because I feel like I get a good night sleep on 5 hours or whatever it is I get, doesn't mean my sleep quality isn't horrible due to apnea, and that maybe over the long term the apnea might kill me.
I think it's the same with hiring. Everyone thinks they do it well; you look around you, feel like you like everyone you work with, and then write up the process that got you there. What's dangerous is if your current success is a fluke, and the process you set up is a recipe to become insular, or a stepping-stone job for SFBA people, or (worst of all) one of those companies you can't work for if you're a mom --- and I know you personally don't want to be any of these things!
You are awesome and I'd love to work with you someday. I just hate the way you say you hire. :)
Having to work 18 hour days is an inevitable consequence of working 18 hour days.
Unlike tptacek, I love the "Sunday test", because it acts as a filter for me -- I'd never work at a place where that question was asked in a non-sarcastic way.
I have to admit though that I don't really get why you'd use the "Sunday test" and the "Caller ID" test, since both are differently worded ways of gauging exactly the same thing. Seems like you could simplify it down to the "Is this guy (or girl) an asshole or what?" test, but I guess just asking it outright like that doesn't give you the same process-hipster cred of having heard of these other "tests".
You're right, and that is the intent of the tests. We don't ask that question of candidates at all, and I just updated the post to clarify that.
It's not about 'process-hipster cred' - most people who know me will tell you I don't give a shit about anything like that. It's about having questions to keep in mind when evaluating a candidate and your ability to work with him/her. "Is he/she an asshole?" is one such question, but these are others that we have found to work well.
Unless a person is at one extreme or the other (on a trait spectrum), I'm not sure I'd be able to tell based on an interview (or series of interviews) whether I would want to hang out with him/her on a Sunday. An extrovert who reads as "fun" within a few minutes may be someone you know immediately you'd like to hang out with. What about the person who is an introvert and reads as "fun" within a few hours, days, weeks. . .? Within a few weeks, you would have realized this is someone you could work with, but you would have already made the decision not to hire this person,
Our interview process isn't 'standard.' It probably isn't scalable to a company of 100, but right now we don't bring a person in for an hour. A few of us are definitely introverts, and it's not about "liking someone" necessarily, it's about being excited to be around them and work with them.
As a founder your job is to take the high road as much as possible while still pushing through the strengths of your company. It seems pretty obvious that NYT won't be changing their opinion, and maybe even reached out to Musk to confirm this suspicion. If Musk were to reply to this negatively he'd essentially be feeding an ever-lasting flame. He's taking the best parts, spinning them to those who care about his product, and is continuing on with building out a great product.
Not to mention, he's gotten a lot of good press from other media sources since (as he points out in his blog post).
If you run a scan from our homepage, you're actually looking for a lot more than just the YAML vulnerability (XSS, Mixed Resource, etc.) as our product isn't limited to just the YAML vulnerability.
Ah, not sure how I got turned around, but yes I was using the scanner from the main page. Thanks for the clarification, and nice work. This is going to help out a lot of people.
