this feels like blocking terms like "null" or "select" just because you failed to properly parameterize your SQL queries.
Writing "/etc/hosts" breaks the Substack editor
311–320 of 370 posts
Re: Writing "/etc/hosts" breaks the Substack editor
#312Just rot13 any request data using javascript before posting, and rot13 it again on the server side. Problem solved. (jk)
Re: Writing "/etc/hosts" breaks the Substack editor
#313Earlier quoted context omitted.
An OutOfMemoryException log should not be the same as a search log Error: OutOfMemoryException And Search: OutOfMemoryException Should not be related in any way
Until someone searches for "Error: OutOfMemoryException"
I read the gp to mean that error.log (being parsed to look for OOM) would have no associations with userSearches.log, in which an end-user searched for OOM
Re: Writing "/etc/hosts" breaks the Substack editor
#314I had a problem recently trying to send LLM-generated text between two web servers under my control, from AWS to Render - I was getting 403s for command injection from Render's Cloudflare protection which is opaque and unconfigurable to users.
The hacky workaround which has been stably working for a while now was to encode the offending request body and decode it on the destination server.
Re: Writing "/etc/hosts" breaks the Substack editor
#315Does it block `/etc//hosts` or `/etc/./hosts`? This is a ridiculous kind of whack-a-mole that's doomed to failure. The people who wrote these should realize that hackers are smarter and more determined than they are and you should only rely on proven security, like not executing untrusted input.
Well I've just created an account on substack to test this but turns out they've already fixed the issue (or turned off their WAF completely)
Re: Writing "/etc/hosts" breaks the Substack editor
#316Earlier quoted context omitted.
There should be some limits and some consequences to the insurer as well. I don't think the insurer is god and should be able to request anything no matter if it makes sense or not and have people and companies comply. If anything, I think this attitude is part of the problem. Management, IT security, insurers, governing bodies, they all just impose rules with (sometimes, too often) zero regard for consequences to an…
> There should be some limits and some consequences to the insurer as well. I don't think the insurer is god and should be able to request anything no matter if it makes sense or not and have people and companies comply. If the insurer requested something unreasonable, you'd go to a different insurer. It's a competitive market after all. But most of the complaints about incompetent security practices boil down to min…
> Forced password changes once every 90 days is dumb and slightly annoying but doesn't significantly impact business operations.
It negatively impacts security, because users then pick simpler passwords that are easier to rotate through some simple transformation. Which is why it's considered not just useless, but an anti-pattern.
Re: Writing "/etc/hosts" breaks the Substack editor
#317Earlier quoted context omitted.
I'm not in an IT dept (developer instead), but I'd bet money that would get you a thorough dressing down by an executive involved with the insurance. That sort of blaming goes over well with those at the bottom of the hierarchy, and poorly with those at the top.
The insurance people are not a part of the company, so I'm not sure who would be offended. I wouldn't be mean about it. I'm imagining adding a line to the email such as: > (Yes, I know this is annoying, but it's required by our insurance company.) What is the insurance company going to do, jack up our rates because we accurately stated what their policy was?
The problem is that this particular insurance company was picked by someone who does work in yours.
Re: Writing "/etc/hosts" breaks the Substack editor
#318Earlier quoted context omitted.
Sorry, we have to reject your comment due to security. The text "Cloudflare s" is a potential SQL injection.
You know, I get the spirit of this criticism. But, specially in the age of AI, we're going to get thousands of barely reviewed websites on Cloudflare. If you know what you're doing, turn these protections off. If you don't, there's one less hole out there.
The problem is that people who don't know what they are doing join the cargo cult and then impose these requirements on people who do know what they are doing.
Re: Writing "/etc/hosts" breaks the Substack editor
#319Earlier quoted context omitted.
I found an example! https://retail.direct.zurich.ch/resources/definition/product... Questionnaire Zurich Cyber Insurance Question 4.2: "Do you have a technically enforced password policy that ensures use of strong passwords and that passwords are changed at least quarterly?" Since this is an insurance questionnaire, presumably your answers to that question affect the rates you get charged? (Found that with the help o…
We've been asked that question before on security questionnaires, and our answer has always been, "Forcing users to change passwords regularly is widely regarded as a very bad security practice, and we don't engage in bad security practices." We've never had anyone complain.
I've never had a complaint about anything I put in to a form requesting a quote for insurance. I just get the quote back. Did you write that in the comment expecting an insurance salesperson to call you up and argue passwords with you? Call their back office and say "hey this guy says our password question is crap, get our best guys on it!"?
I just cant imagine any outcome other than it was translated to just a "no" and increased your premium over what it would have otherwise been.
Re: Writing "/etc/hosts" breaks the Substack editor
#320Earlier quoted context omitted.
I remember back in the old days on the Eve Online forums when the word cockpit would always turn up as "c***pit". I was quite amused by that.
This is actually a better solution, replacing dangerous words with placeholders, instead of blocking the whole payload. That at least gives the user some indication of what is going on. Not that I'm for any such WAF filters in the first place, just if having to choose between the lesser of two evils I'd choose the more informative.
Not so sure. Imagine you have a base64 encoded payload and it just happens to encode the forbidden word. Good luck debugging that, if the payload only gets silently modified.
I suddenly understand why it makes sense to integrity-check a payload that is already protected by all three of TLS, TCP checksum and CRC.