I came upon an article titled Are You Suffering From the Curse of Knowledge? recently in a reddit thread.
Another famous example is that of an extremely successful salesman for IBM who was asked by an interviewer why he was so good at sales, to which he responded, “It’s because I stopped coughing!”
A couple of experts in sales were so confounded by his answer that they decided to examine him more closely. After a while they found that he was actually doing a lot of things really well—he was using a ton of sales tactics brilliantly, he just wasn’t aware of it. He was naturally talented at sales.
The moral of this little story is that the IBM sales guy falsely attributed the reasons for why he was so successful.
The secrets of success from the top scorers in an examination might actually not be the secret sauce that led them to those results. Sometimes it’s not obvious why someone is doing really good.
TLDR: You can’t
There’s a writeup on a newly found vulnerability in Adobe Acrobat Readers:
We all know that void pointers are by definition typeless, may point to any object, and any object may be cast to it. But surely, after we’ve cast an object pointer to a void pointer, it’s still possible somehow to detect its origin type, right? Not quite.
Once an object is cast to a void pointer, it’s absolutely impossible to detect its origin type. So, how do we check the type of a void*? The answer is that we don’t. And when you try, what you get is a vulnerability.
In case you’re not familiar with void pointers in C/C++, you can assign _any_ pointer to a void pointer, regardless of the type.
void *ptr = any_ptr;
This can be helpful if you don’t know what kind of a pointer you will receive in a function, etc. But usually it’s better to avoid them like the plague.
Troy Hunt has a nice article about inline-scripts and CSP with some practical examples.
By default the following CSP directive will block all inline scripts:
Content-Security-Policy: default-src 'self'
The most straight-forward way to remove the restriction is to add unsafe-inline but it disables all the defenses against inline scripts and XSS. Thankfully you have two alternatives: using a hash or a nonce. (TIL!)
If the script is static (the content does not change), you can add a SHA-256 hash of the script to the CSP directive, so the script will be whitelisted.
Content-Security-Policy: default-src 'self'; script-src 'sha256-blLDIhKaPEZDhc4WD45BC7pZxW4WBRp7E5Ne1wC/vdw='
However, if the script is prone to change, you have the option of adding a base64-encoded nonce (random value) to both the CSP directive and the script tag.
Content-Security-Policy: default-src 'self'; script-src 'nonce-4AEemGb0xJptoIGFP3Nd'
<script type="text/javascript" nonce="4AEemGb0xJptoIGFP3Nd">
Dan Fabulich has a post titled I Watched All of the Chrome Dev Summit 2017 Videos So You Don’t Have To:
tl;dr: Google wants you to build PWAs, reduce JavaScript file size, use Web Components, and configure autofill. They announced only a handful of features around payments, authentication, Android Trusted Web Activities, Chrome Dev Tools, and the Chrome User Experience Report.
Check out the full post for a more detailed summary.
This is three weeks old and I kept putting off posting this in AH. It’d be super cool if someone wrote TLDRs for all conferences happening everywhere.
Tweet by sarah_edo:
A lot of people, mostly university friends, called me during last month after they learned that I was unable to walk due to a leg injury. People don’t forget to leave some advice during the calls. These include:
* Migrate to another country (from those who have already migrated to other countries)
* Live for a few years in a different country (from those who are abroad temporarily for work reasons)
* Marry ASAP (from those who are married)
* It’s time I should marry and have some kids (from those who are married and have kids)
* Build a house (from those who own houses)
* Switch to a better car (from those who have more expensive cars)
* Get the shit together (from someone who has theirs together, probably)
I’m not bluffing – this is 100% real. I’m thankful for all the advice, but I feel worse than ever now.
Came across an easy-to-follow article on how random number generators, or LCGs, work.
One thing we haven’t addressed yet, is the issue of deciding the initial seed. We could fix it to some constant number. This is useful in cases where you need random numbers, but they have to be the same every time the program is executed — generating the same map every game for example.
Another way to decide the seed is to fetch it from a source that is different each time the program is executed — like the system time. This useful in a case where a general random number is needed, like a program to simulate a dice roll.
Antonio Sanso writes:
This means that if I present to a ServiceProvider A an assertion meant for ServiceProvider B, then the ServiceProvider A shoud reject it.
Well between all other things I tried this very really simple attack against a Slack’s SAML endpoint /sso/saml and guess what? It worked 😮 !!
To be more concrete I used an old and expired (yes the assertion was also expired!!) Github’s Assertion I had saved somewhere in my archive that was signed for a subject different than mine (namely the username was not asanso aka me) and I presented to Slack. Slack happily accepted it and I was logged in Slack channel with the username of this old and expired Assertion that was never meant to be a Slack one!!! Wow this is scary….
Scary indeed. And it isn’t a particularly sophisticated hack either. Slack has now patched the issue.
Came across this nice cheatsheet with awk examples on Hacker News today: Github link
awk is a highly underrated Unix utility. I’ve seen very few developers use it, but it’s both powerful and useful. Awk is a language of its own, but you don’t need to master it to start using it.
Some time back, I moved a large bunch of files to a home directory in a server by mistake. I had used the following (naive) command to move them back to the original location (according to my notebook):
ls -ltr | grep '14:57' | awk '{print $8}' | xargs -I '{}' mv {} vftemp
Apparently I had exploited the fact that the moved files all had the 14:57 time stamp and filtered them with grep, and then used awk to get the 8th column of the list, which should have been the filenames and moved them back.
A high school mathematics teacher interviews Andrew Wiles. Wiles is one of the most famous mathematicians in the world today; best known for proving the 350-year-old Fermat’s Last Theorem.
Wiles explained the process of research mathematics like this: “You absorb everything about the problem. You think about it a great deal—all the techniques that are used for these things. [But] usually, it needs something else.” Few problems worth your attention will yield under the standard attacks.
“So,” he said, “you get stuck.”
“Then you have to stop,” Wiles said. “Let your mind relax a bit…. Your subconscious is making connections. And you start again—the next afternoon, the next day, the next week.”
Patience, perseverance, acceptance—this is what defines a mathematician.
Tweet by @jschauma:
Whenever a browser makes an HTTP request to a server, the browser sends in a User-Agent header, so the server can know what kind of a browser/agent the request is coming from. I’m writing this post in a Safari browser in macOS and the string it sends is:
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/604.1.38 (KHTML, like Gecko) Version/11.0 Safari/604.1.38
It says Mozilla at the beginning, but it’s not Firefox.
Confusingly, the User-Agent string of Google Chrome has both Mozilla and Safari in addition to Chrome:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36
These strings will change depending on both the browser version and the OS you are on.
While these strings seem cryptic, you can use this handy guide from MDN to identify the browser from User-Agent strings: https://developer.mozilla.org/en-US/docs/Web/HTTP/Browser_detection_using_the_user_agent#Browser_Name
