way back in time i was tasked to write a JSP based web tool with which one could submit SQL queries against a database server (yes, really :) ) The first manual tests were a complete failure. No request made it from the browser to the web server. This was done in a corporate network. Eventually i figured out that some security feature just dropped every HTTP packet which contained a number of SQL keywords above some threshold. Too bad for a web based SQL query tool. My workaround was to encode the SQL in the browser in rot13 using java script, and decode it on server side. IIRC this was about 20 years ago.
The real fun begins if you try to report such a bug to substack. Probably the worst customer support experience I've ever encountered is trying to get a human at substack to follow up with me about a technical issue. The bot is dumb as rocks.
This raises the interesting possibility of using hacking maneuvers to try to get your content around CloudFlare and into Substack.
Try #1: "o" is a valid unicode character with a simple html escape (o), maybe that passes through?
Try #2: if you were to send with transfer-encoding chunked, could you accidentally split the chunks on the offending pathname and still get the article up into substack?
Junk characters that get removed would also be viable, like zero width unicode spaces. I'm actually almost certain that would work since that actually makes it a different path entirely and there's no reason to block it for a WAF.
I recently debugged an issue where our React app was mysteriously not loading in my colleague's browser. The TLDR is his browser had a `referrer` cookie set to `localhost:3000` and our AWS WAF was blocking his network calls because of a rule that filters out "localhost".
It was quite a challenging and tedious issue to pinpoint.
Had this type of filtering on the previous companies internal "wiki" knowledge base. We could not document things for the future. We resorted to put a readme into the code, check it in to git and reference that textfile from the wiki. ("for commands needed, read /project/readme.md")
Thanks for the great analysis! I wish I had read this a week ago! I finally figured out why several of my posts were giving me the network error just by brute force adding a little more to them until they failed. Here was one of them: https://readplanet.substack.com/p/six-bash-tricks-you-can-use-daily
My answer? Not very elegant:
(Note: Substack crashes when you have the filename for your passwords. Therefore, the listing below says /etc/pa_ss_wd but you should take the underscores out when you really try this example.)
I would recommend trying a workaround which is to insert Unicode character U+200B (zero-width space) somewhere in the path you're trying to write. I haven't tested it but I would expect that would be a sensible (if not super convenient) solution?
I am open to work: https://www.linkedin.com/in/lee-gaines/
way back in time i was tasked to write a JSP based web tool with which one could submit SQL queries against a database server (yes, really :) ) The first manual tests were a complete failure. No request made it from the browser to the web server. This was done in a corporate network. Eventually i figured out that some security feature just dropped every HTTP packet which contained a number of SQL keywords above some threshold. Too bad for a web based SQL query tool. My workaround was to encode the SQL in the browser in rot13 using java script, and decode it on server side. IIRC this was about 20 years ago.
The real fun begins if you try to report such a bug to substack. Probably the worst customer support experience I've ever encountered is trying to get a human at substack to follow up with me about a technical issue. The bot is dumb as rocks.
This raises the interesting possibility of using hacking maneuvers to try to get your content around CloudFlare and into Substack.
Try #1: "o" is a valid unicode character with a simple html escape (o), maybe that passes through?
Try #2: if you were to send with transfer-encoding chunked, could you accidentally split the chunks on the offending pathname and still get the article up into substack?
Junk characters that get removed would also be viable, like zero width unicode spaces. I'm actually almost certain that would work since that actually makes it a different path entirely and there's no reason to block it for a WAF.
The same issue exists in Twitter / X, you cannot mention hosts file
I recently debugged an issue where our React app was mysteriously not loading in my colleague's browser. The TLDR is his browser had a `referrer` cookie set to `localhost:3000` and our AWS WAF was blocking his network calls because of a rule that filters out "localhost".
It was quite a challenging and tedious issue to pinpoint.
/etc/./hosts
And so you notified Substack right?
Had this type of filtering on the previous companies internal "wiki" knowledge base. We could not document things for the future. We resorted to put a readme into the code, check it in to git and reference that textfile from the wiki. ("for commands needed, read /project/readme.md")
Thanks for the great analysis! I wish I had read this a week ago! I finally figured out why several of my posts were giving me the network error just by brute force adding a little more to them until they failed. Here was one of them: https://readplanet.substack.com/p/six-bash-tricks-you-can-use-daily
My answer? Not very elegant:
(Note: Substack crashes when you have the filename for your passwords. Therefore, the listing below says /etc/pa_ss_wd but you should take the underscores out when you really try this example.)
cat /etc/pa_ss_wd
cat /etc/pa_ss_wd | column -t -s :
That is nuts.
I would recommend trying a workaround which is to insert Unicode character U+200B (zero-width space) somewhere in the path you're trying to write. I haven't tested it but I would expect that would be a sensible (if not super convenient) solution?
Presumably the Substack client library should do this, or something similar, automatically, rather than foisting the effort onto users.
Another common workaround is making pictures with the command text and putting that in the post.
Noting, however, that readers could not copy/paste that path and have it work on their own machines... hmm
in modern world, you don't copy&paste any more - you make AI do that ;-)
copy&paste system commands - what a security nightmare - better have AI typing in the root shell
/irony{off}