Hacker Newsnew | past | comments | ask | show | jobs | submit | genzer's commentslogin

I argee. Up until now, the most PITA for me in Markdown is the table syntax. Even CommonMark does not have any spec for table except for long running discussions with lots of proposals.

AsciiDoc(tor) has a nice support for tables. It also supports more complex features like merged cells, span cols and all but the syntax suffers from there. I guess that is also why AsciiDoc was not widely adopted.


Ever since I found `asdf`, I threw away jenv, nvm, fmn and rvm.


Same here, having a different version manager per language ecosystem got tiring due to the small differences.

I used asdf for a while but moved to mise-en-place (mise). Same reasons though, one tool manager for all the tools.


This made me laugh out loud! So much related!

Ever since I discovered `act` [1], I made a lot less commits.

[1]: https://github.com/nektos/act


The vulnerability came from the outlook-integration.harvestapp.com. It used a JSON object as `state` containing instructions once the OAuth2 Callback succeeded.

The property `subdomain` was used to redirect the browser to a subdomain of harvestapp.com, passing the `#id-token`. The problem came from the fact that the value of `subdomain` was injected directly to:

https://${subdomain}.harvestapp.com/...#id-token=...

By setting the `subdomain` in JSON payload to `attacker-controlled.com/` (note the trailing slash), the URL become:

  https://attacker-controlled.com/.harvestapp.com/...#id-token=..
..thus redirects the browser to another domain, leaking the token.


So it was the combination of:

* the additional redirect using the JSON object in state * the `subdomain` not being properly verified * the implicit grant being supported

Which allowed an attacker to get an access token for a user's Microsoft account.

From my reading, this seems to be entirely an issue due to an improper implementation on Harvest's side, nothing to do with Microsoft's implementation of OAuth. Am I correct?


Clearly not, or I doubt we would be reading this blog post.

I assume that for several years though, that was exactly what Microsoft thought too.


What am I missing then?

It seems pretty clear to me from reading the blog post that the issue was what I outlined (sorry for the lack of list formatting, I always forget I need an extra line after each bullet point).


Not sure what parent was talking about. You are correct. This is Harvest’s responsibility, not Microsoft’s.


I didn't understand the article correctly. I was wrong.


Good explanation. Quick follow up, so to resolve this issue, what I have in mind are :

1. Make sure the redirect url is a valid harvestapp.com (more checks on state)

2. Encrypt the state since the start of the request, so then they can double check the state hasn't been forged by decrypt and compare

Is there any option beside those?


All they had to do was sanitize the subdomain var to only allow values valid in host part of a URL. But also, one of the state parameter's primary uses is exactly to prevent XSRF attacks like this by using a random nonce value so that you can validate from the redirect that your system was the initiator of the auth request. The data in this state was not sensitive, so encryption is not really necessary.


Why not just use a random ID and pull from DB instead of shuffling around a json payload? Really trying to avoid that DB hit? Just pay the price imo


Have you tried YouTube Kids? I allow my daughter using only YouTube Kids (in kid mode) on my Android phone. The suggested content was good enough. Google also allowed you to supervise the content [1].

[1]: https://support.google.com/youtubekids/answer/7178746#block_...


I tried YouTube Kids, but found it was suggesting a lot of surprise egg and colorful slime videos. I blocked those channels, but more showed up, so I deleted the app.


Its only usable (in my opinion) in the allow list channel mode. Otherwise its never ending reaction blocking.


This reminds of the journey of the creator of icanhazip [1]. He had created it and maintained it through several milestones _on his own_ until he could no longer carry on. Luckily it ended on a good note as Cloudflare decided to "buy" it.

[1]: https://major.io/2021/06/06/a-new-future-for-icanhazip/


The anwser is just one Google away: Yes. The Wikipedia has a page dedicated to it [1].

[1]: https://en.m.wikipedia.org/wiki/Private_browsing#Support_in_...


I just tried using Kill the Newsletter! on Farnam Street [1] and the experience was awesome. Simple, fast, free and no ads.

Thanks for introducing a very good tool!

[1]: https://fs.blog/


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: