Ryan Armstrong

@OreoB1scuit This is a solid series. You may also be interested in my related YouTube series: youtube.com/watch?v=JVNDAe…

Beyond The XSS aszx87410.github.io/beyond-xss/en/ #bugbounty #bugbountytips

@shakquraa You might be interested in my recent YouTube series: youtube.com/watch?v=JVNDAe…

Client-Side Bug Hunting 💀💀

@0xTib3rius There are additional possibilities with examples here: blog.ropnop.com/storing-tokens…

The "where to store JWTs" debate is complicated and not without nuance. It's important to realize that there is no 100% secure answer. That is to say, whatever answer you give, there are associated weaknesses that you must be aware of. A lot of people will argue that if your app is vulnerable to XSS, cookies with HttpOnly are at least protected from JavaScript, while Session/Local Storage are designed to be accessed by JavaScript. This might seem like cookies have a big advantage, but what this really means is that cookies cannot be stolen. However, since the browser automatically adds cookies to requests, any XSS attack could send valid requests and steal the data from the responses. So yes, while you don't get the actual session token, you can still use it, which is ultimately what an attacker wants to do anyway. Moreover, if you rely on cookies, your app needs to protect itself against CSRF. This has become easier with SameSite cookie attributes, but they are not without their limitations (portswigger.net/web-security/c…). If you use Session/Local Storage and set session tokens via a non-Cookie header (e.g. Authorization), CSRF is impossible. It's important to note that if your app is vulnerable to XSS, all your CSRF protections will fail regardless of how you store session tokens. Finally, people suggesting Session Storage over Local Storage face the issue that Session Storage is per-tab not per-site. If you store a session token in Session Storage, then right-click a link in your app and "Open in new tab", you will be logged out in that new tab. This is not me arguing for / against a particular method. As I said at the start, there is no 100% secure solution. This is a brain dump of some of the weaknesses each has so people can make more educated decisions. 🤷

Excited to welcome @ryarmst onto the @OWASP_ASVS working group! As a long-time user and recent contributor, Ryan brings his insights in using ASVS for pen testing engagements to help us improve for version 5.0!

The first ASVS Community Meetup was a great success! Thanks to @jit_io for the support! We had great talks from @manicode, @dcuthbert, @joshcgrossman, @IreneMichlin and Alex S, and super interesting discussions. Full details in our blog post: owasp.org/blog/2024/07/0…

@pentestlist @intigriti I would if I had the time!

@ryarmst @intigriti We'd love it if you submit it to our community driven website and earn yourself some karma 😃

Do you test websockets for vulnerabilities? What are your favorite tools for it? 🤠

The sophistication levels of online scammers that are targeting individuals and families is hitting an all time level. Just dealt with a friend that drained all their bank accounts, SIM cloning, and had full voice cloning (to remove accents + sound perfect) and kept them on phone as they depleted accounts. Super methodical, well prepared, precise, and had all their prior breach data at hand. This wasn't your antivirus is out of date, this was starting off: 1. Well prepared pre-text using prior breach data as initial trust gainer. 2. Chase fraud services spoofed number with caller ID. 3. Directed them to a fake FTC 800 number to report claim. 4. Already knew all their bank accounts, SIM cloned to get one time pin, through carrier due to credential stuffing. 5. Delay them as bank accounts were depleted and locked out of accounts to not recall funds. Definitely gave me the beekeeper movie vibes.

Chiropractors again banned from giving Australian babies spinal treatment. Canada should do the same. ⁦@ryarmst⁩ ⁦@picardonhealth⁩ ⁦@CaulfieldTim⁩ ⁦@VikCBC⁩ ⁦@NightShiftMD⁩ ⁦@ScienceBasedMed⁩ ⁦@MaryFernando_⁩ theguardian.com/australia-news…

Coming to the @OWASP ASVS Community Meetup at Global AppSec Lisbon? We need your input! What would you like to see/do at the meetup? Let us know by answering a few questions: docs.google.com/forms/d/e/1FAI…

@pentestlist @intigriti Missing a very useful Burp extension: youtube.com/watch?v=Ztk93V…

@intigriti @pentestlist > Tools > Search for "Websocket" Boom, three tools you can use to test websockets 👊

"the Pentagon used a combination of fake social media accounts on multiple platforms to spread fear of China’s vaccines among Muslims at a time when the virus was killing tens of thousands of people each day" reuters.com/investigates/s…

@Scott_Helme @JoshCGrossman @OWASP_ASVS I don't think that's quite the case. I can think of scenarios where even following something like the "strict CSP" approach there could exist attacks that succeed without triggering a violation.

@ryarmst @JoshCGrossman @OWASP_ASVS Right but neither of those scenarios matter. Local dev, they’re in control and obv no reports. An attack allowed by CSP is a CSP derp, you need to fix your policy. If you have an effective CSP in place, you’re good.

Hey @Scott_Helme, we're chatting about CSP over at @OWASP_ASVS and I thought, who do I know who is a CSP expert :) So: Do you see CSP violation reports as a key security control that should be mandated or more as a usability/debugging aid? #issuecomment-2091809694" target="_blank" rel="nofollow noopener">github.com/OWASP/ASVS/iss… cc @ryarmst

@Scott_Helme @JoshCGrossman @OWASP_ASVS @reporturi Of course, and I've never claimed reporting is not an important practice. We recommend it to clients as part of the process of deploying CSP. I just have not seen the evidence of violation reporting being effectively used to identify potential XSS attacks in practice.

@ryarmst @JoshCGrossman @OWASP_ASVS @reporturi It’s also worth noting that XSS isn’t the only thing of note that people are interested in monitoring for.

@Scott_Helme @JoshCGrossman @OWASP_ASVS @reporturi Can you link the blog post? I have not seen many such cases reported/documented publicly, but I trust your account of it, thank you. Similarly, I have largely only seen clients using reports to refine their policies for functional reasons.

We process 500,000,000+ CSP reports per day at @reporturi, but there’s not much I can talk about publicly. The vast majority of our customers use reports to refine their policy and then move to monitoring for violations for serious incidents. I have many cases where actual XSS has been found, many! Including one on our site that I covered on my blog.

@Scott_Helme @JoshCGrossman @OWASP_ASVS There would, however, be situations where an attacker is not able to evaluate their own payloads in a controlled environment/browser (such as blind attacks).

@Scott_Helme @JoshCGrossman @OWASP_ASVS Assuming the attacker develops the attack in their own browser and app context, they can test/experiment without sending reports. If they can then develop a payload that works and does not trigger CSP, the attack proceeds with no violation logs from the full process.

@Scott_Helme @JoshCGrossman @OWASP_ASVS @Scott_Helme do you have available any case studies or data on orgs identifying and mitigating XSS vectors primarily from CSP violation reports?

@Scott_Helme @JoshCGrossman @OWASP_ASVS We have always recommended reporting regardless, but I've seen it more as a tool to properly deploy a CSP without breaking page functionality.