Said tokens didn't have admin access, but had enough privileges to invite other users to become full admins. Not sure if they were rotated, but github tokens are usually long-lived, like up to a year. Hey, isn't AWS the one always lecturing us to use temporary credentials? To be fair, AWS did more than just fix the regex, they introduced an "approve workflow run" UI unto the PR process that I think GH is also using now (not sure about that).
Ah... Github permissions. What fun.
Github actually has a way to federate with AWS for short-lived credentials, but then it screws everything up by completely half-assing the ghcr.io implementation. It's only available using the old deprecated classic access tokens.
Obviously, GitHub needs to just fix this nonsense. But I interviewed a couple of "senior" engineers from GitHub, and I have zero hope of that happening soon.
Regexpes for security allow lists: what could possibly every go wrong uh!?
For each bug you find, write a failing test. Run the test to make sure it fails. If it passes, try 1-3 times to fix the test. If you can't get it to work, delete the test and move on to the next bug.
> I tossed out some tests that were asserting they could index a list at `foo.len()` instead of `foo.len() - 1`.
That said, what this regex wanted to be was obviously just a list. AWS should offer simpler abstractions (like lists) where they make sense.
Agree. I would understand if there was some obvious advantage here, but it doesn’t really seem like there is a dimension here where regex has an advantage over a list. It’s (1) harder to implement, (2) harder to review, (3) much harder to test comprehensively, (4) harder for users to use (correctly/safely).
Wrong tradeoff, to be sure.
It's also this context that reveals how much simpler strict regular expressions are than general purpose programming languages like Python or JavaScript. That simplicity is also part of what makes regexes so ubiquitous: due to its lower computational complexity, regex parsing is really fast and doesn't take much memory.
When I say regexes are simple, I'm not really talking about compactness. I mean low complexity in a computational sense! As someone who rather likes regex, I think it would be totally fair for a team to rule out all uses of PCRE2 that go beyond the scope of regular languages. Those uses of regex may be compact, but they're no longer simple.
I'm also someone who is sensitive to readability-centered critiques of terse languages. Awk, sed, and even Bash parameter expansion can efficiently do precise transformations, too. But sometimes they should be avoided in favor of solutions that are more verbose, more explicit, and involve less special syntax. (Note also that Bash, awk, and sed are also all much more complex than regex!)
What is the claim? That it is compact for simple cases. Well Brainfuck is a compact programming language but I don't see it in production. Why?
Because the whole point of programming is that multiple eyeballs of different competence are looking at the same code. It has to be as legible as possible.
Again, this is too binary a way if thinking. There are string matching operations which are not parsing source code and regular expressions can be a concise choice there. I’ve had cases where someone wrote multiple pages of convoluted logic trying to validate things where the regular expression was not only much easier to read but also correct because while someone was writing the third else-if block they missed a detail.
From everything I know about pentesting, they should have stopped before doing this, right? From https://hackerone.com/aws_vdp?type=team :
> You may only interact with accounts you own or with explicit written permission from AWS or the account owner
This is oftentimes political. The CISO wants additional budget for secure coding training and to hire more security engineers, let the pentesting firm demonstrate a massive compromise and watch the dollars roll in.
A lot of time, especially in smaller companies, it's the opposite. No one is responsible for security and customers demand some kind of audit. "Don't touch anything we don't authorize and don't do anything that might impact our systems without explicit permissions."
Wiz is a very prominent cloud security company who probably has incredibly lucrative contracts with AWS already, and their specialty, as I understand it, is identifying full "kill chains" in cloud environments. From access issues all the way to compromise of sensitive assets.
Glad to see a few more security knobs on actions these days!
This article lends some credibility to that notion.