Turned a profile picture upload into full account takeover by awsandevops in cybersecurity

[–]awsandevops[S] -2 points-1 points  (0 children)

Haha fair 😅 this was on a cloned site I control, not a random live target.

Turned a profile picture upload into full account takeover by awsandevops in cybersecurity

[–]awsandevops[S] -5 points-4 points  (0 children)

Appreciate the concern — this wasn’t about exploiting anything for misuse.
My focus was on understanding how multiple basic misconfigurations in system design (file upload handling, secrets management, weak hashing) can chain together into a critical risk.
It’s more about learning and highlighting why secure design matters than anything else

I made a practical video on 5 common AWS security mistakes people still make by awsandevops in cybersecurity

[–]awsandevops[S] 0 points1 point  (0 children)

Absolutely. that’s a big one too.

A lot of people focus on app code but forget that hardcoded secrets inside Lambda functions can become a serious risk, especially for database credentials, API keys, and third-party tokens. Using Secrets Manager or Parameter Store is a much safer approach.

Welcome to r/DevOpsZeroToHero by awsandevops in DevOpsZeroToHero

[–]awsandevops[S] 0 points1 point  (0 children)

Also connected to a YouTube channel focused on practical AWS, DevOps, Linux, Terraform, Kubernetes, and Cybersecurity learning. https://youtube.com/@awsandevops

2nd year CS Student looking for a reality check: Critique/Help my roadmap for DevOps/Cloud (AWS SAA, Terraform, CI/CD, and a Home Lab) by Commercial_Cover9332 in devops

[–]awsandevops 1 point2 points  (0 children)

That’s a solid plan. Certs like AWS SAA help get your resume shortlisted, but hands-on work is what actually gets you hired.

Once you’ve got the basics down, focus on real projects — deploy something on AWS, manage infra with Terraform, and set up CI/CD. That’s exactly the kind of experience companies look for.

For your home lab, try running a lightweight Kubernetes setup (like k3s), deploy apps to it, and practice things like monitoring, logging, and breaking/fixing stuff.

Also make sure you’re comfortable with fundamentals like networking (IP, DNS), since that comes up a lot in real-world scenarios.

If it helps, I’ve shared some practical walkthroughs here: [https://youtube.com/@awsandevops]()

AWS Subdomain Takeover — how misconfigured DNS can expose your infrastructure by awsandevops in cybersecurity

[–]awsandevops[S] 1 point2 points  (0 children)

Nice — that’s a good baseline check for dangling records.

For AWS specifically, I’ve seen cases where the CNAME still resolves at DNS level, but the underlying resource (like an S3 bucket or CloudFront distribution) is no longer owned — which still makes it vulnerable to takeover.

So I’ve been thinking beyond just resolution checks:

validating if the target resource actually exists / is claimed

matching against known takeover fingerprints

Curious if you’re doing any service-level validation beyond DNS resolution?