yoloClin

Broken access control is things like direct object vulnerabilities and authorisation bypasses _as well_ as broken authentication controls.

I'm not saying you're wrong, and agree that security should never be a 'premium' product, but it's important to identify that it isn't _just_ limited to authentication.

That being said, messing with SAML/Oauth assertions is generally pretty fruitful when pentesting, and MFA is something I'd recommend in almost all public facing applications.

Friendly reminder that this is about frequency, as opposed to severity. 'Cryptographic Failures' is everything from theoretical vulnerabilities which require millions of dollars to exploit, through to systems with no encryption whatsoever. Granted both should be fixed, but the latter is of far more real world consequence under most threat models.

My personal and current recommendation for developers is to focus on sane authorisation models - I commonly see direct-object type vulnerabilities related to cross-user/organisational access where the user is the correct role / privilege level to access a resource, but has no association with the record owner. An example of this would be a a multi-tenant web-store where an admin for the EvilCorp entity can modify products belonging to InnocentPtyLtd.

I also suspect poorly configured CORS policies might be in the top 10 in a few years time due to situations where SPA apps (who will inevitably use JWT) and traditional cookie apps are hosted using similar configs, resulting in the latter being vulnerable to CSRF-type attacks.

This. I want a shell that will contextually spit out plaintext in interactive mode, then a JSON object when scripted or piped.

Pretty sure this is what Powershell does, but the UI just feels so damn unnatural.

I really like Reveal.js.

I feel the design constraints enforced (size / amount of text per slide) is awesome, but at the same time very limiting for technical presentations where large amounts of text data is pretty important.

Does anyone else have this issue / work around it? Maybe I suck at designing slide decks, but I just feel that the ability to break design rules easily is sometimes a must-have.

On the flipside, it's more plausible for an actor to get malicious code into a project in order to infect a target. Sure it has to be obscure enough to pass any code reviews during PR and/or involves compromising a contributor but it is possible and something I see happening in the next 10 years.

I'm also genuinely curious how many people actively review all the code they actually run. I doubt anybody but the very largest tech companies and high-end government would actually be able to afford and resources such a feat, and even then they would have DMZ-type areas to detonate unaudited software.

I agree with CSP, but as I've commented on another thread I recommend CSP _with_ other mitigation factors due to DOM/HTML injection, and browser support.

I think the best solution is CSP _and_ injection mitigations - even without XSS there is still DOM injection which can be equally damaging reputationally.

iirc, IE11 (under Windows 7, specifically) does not support CSP. I don't think CSP mitigates all XSS vectors either (`<a href="javascript:alert(1)">` for example). Sure IE11 is deprecated but that doesn't mean you don't need to account for it when building an enterprise application.

I'm curious if you can provide any details on what / how Safari was exploitable with CSP - https://caniuse.com/?search=content-security-policy indicates that it should be pretty uniform across popular browsers. If you'd prefer a private channel @yoloClin on twitter.

Ping me on twitter. @yoloClin

Thanks, that's exactly what I want!

Is anyone able to provide a map of modern frameworks? With React-native, React-redux, Angular, Vue and probably a bunch of others.

I'm really not sure what's relevant now and what was relevant 6 months ago. I'm genuinely curious, but it's pretty difficult to grasp and no framework homepage is going to tell you "Don't use me, I'm about to be a dead project!" and every developer will tell you their preferred framework is the best framework.

HTML Code Golf - How to make really small _extremely fragile_ HTML that doesn't break Firefox or Chrome, currently at least

FTFY

I just disable it:

``` #!/bin/sh

# Disable capslock setxkbmap -option caps:none

# Better repeat rates # Previously set in lxdm.conf (arg=/usr/bin/X -ardelay 175 -arinterval 20 xset r rate 150 75 ```

I've added another hack in there that I absolutely love for free (:

Hey thanks for this, nushell looks really interesting! I really like the idea of an objective shell but don't like the verbosity of PowerShell inputs. I think if you go through my post history I actually describe wanting something like Nushell, not knowing it existed!

What I'm talking about is a UI/UX problem that cannot be solved by key layout, I even experimented with a Ergodox and ended up in keybind hell really quickly because supporting one application others very quickly.

I fee like UI/UX needs to be completely redesigned and dvorak isn't even half (or any) of the battle. Single-key copy/paste, undo/redo, keyboard driven UIs, etc etc. I say this as I type on dvorak and while I love it, I also regret it due to interoperability issues and breaking of common keyboard shortcuts (I miss Ctrl+CVX).

But I just aliased `us` and `dv` to setxkbmap shortcuts, so thanks for that!

Mike Zamansky has a pretty decent series which focuses mostly on third party package features - https://www.youtube.com/watch?v=49kBWM3RQQ8&list=PL9KxKa8NpF...

I had multiple friends pull me aside about similar email and asked to deal with it confidentially, I've probably had other friends pay up in attempt to avoid humiliation.

I think it's well worth talking to friends and family about these types of scams and how to deal with them - they can cause an immense amount of stress, humiliation and potentially financial stress. Nobody deserves to be put through this kind of abuse.

I'm from a country with public health care, so this comes as an interesting shock - would employees immediately lose health benefits if made redundant / fired etc?

Seems to incentivize getting rid of people when they need healthcare the most (eg "I have cancer" -> "Look, we're going to have to let you go, your performance the past few months hasn't been up to scratch"). I assume there'd be a bunch of health related after-effects to jobloss too, particularly around mental well-being.

I'm more curious about how DB rollbacks occur in situations where a PR changes DB and is then reverted.

Irrespective of who's right or wrong it's pretty unnecessary to call each other names just because you don't agree, particularly when the question is theoretical and has almost no real world impact.

Transport encryption with PKI.

The issue is an injection attack. The ability to insert either unsanitised HTML data or data reflected inside the context of a JavaScript code block which results in JavaScript execution (by <script> tags, being able to specify data in DOM element events such as onClick or onError, or being able to specify code in onClick/onError events). I don't consider this a flaw in JavaScript itself, rather how JavaScript is harnessed from HTML.

Once JavaScript execution is obtained* it's possible to inject a JavaScript keylogger and/or rewrite the DOM to request authentication details from the victim (resulting in credential compromise). Alternatively, it's possible use AJAX to perform GET/POST requests to the same domain, routed through the victims browser which includes all cookies etc - effectively this is a time-boxed account compromise (CSRF controls do not apply when requests are executed from the local domain).

It's also possible to coerce a browser into triggering the exploit in a hidden iframe on a completely different page (eg you browse to evil.com, there's a hidden iframe which exploits an XSS vulnerability on facebook.com, compromising your facebook account if your currently logged into facebook on the exploited browser). I'm pretty sure samesite=strict only fix this if the XSS vector on facebook.com requires the user to be authenticated prior to exploitation, similarly, samesite=lax will not prevent attacks which require authenticated POST primitives.

*I'm a pentester, so that's sometimes my job, I don't break laws.

IMO, using DNS for anything other than hostname lookups is a complete hack. I'm looking at you, SPF.

Secrets stored in cookies really shouldn't be accessible, the Set-Cookie HttpOnly flag should stop all JS access to a cookie. The HttpOnly flag still submits a cookie when you do an ajax GET/POST, but you cannot access the cookie via document.cookie or similar.

There's also external resource integrity checks which prevent modification of third party resources without breaking the local site. jQuery CDN code snippets do this by default: https://code.jquery.com/ .

You can't trust one script to access a cookie without trusting all scripts to access the same cookie though - while I can see some merit to the idea when it comes to hiding secrets from XSS/untrusted code, I'd say that in most (99.9%) situations effort would be better spent actually implementing CSP and good data sanitation rather than caring about implementing JavaScript level trust models.

It would have been much easier to say that if weaponised, an XSS vulnerability can access resources across the entire domain as if they were the victim, and should effectively be considered an account hijack of any exploited victims.

It really has nothing to do with homepaths, or even user-supplied data whatsoever.

Firstly, I'd fix the damn spelling of the referer header instead of everybody putting up with it for close to 30 years.

I don't think it's that JavaScript and HTML are a bad choice, but there are some things that would have made life a lot easier if they were strongly enforced sooner, including secure cookies by default, SameSite=lax, removal of referer header and CSP - doing them sooner would have stopped bad developer practices while also removing a fair chunk of application security complexities, but at least we're moving towards a better world regarding those now.

I don't know if it'd be technically possible to implement, but additional characters to mark unsafe strings would have a huge impact on webapp security. Reflection of untrusted data at the moment generally relies on one of: HTML encoding, URL encoding or JavaScript escaping and escaping a safe way is highly context-dependent (I've seen an unescaped "\n" cause injection within JavaScript contexts). A way of effectively storing the level of trust a chunk of data has across multiple transports when marking untrusted data including within HTML/JS, SQL statements and interpreted languages like BASH or PHP - this would eliminate a bunch of vulnerabilities and would probably have mitigated a bunch of notable historic vulnerabilities and/or hacks.

I don't disagree that segregation is still important, but it really depends on specific environment technical details and threat models.

Firewalling AD networks, for instance, really won't help if the administrative security model is flawed (network admins using privileged account to maintain endpoints, privileged local administrative/maintenance credentials being reused on critical infrastructure, etc). The communication protocols for administration and general use are iirc pretty much require bidirectional traffic to work.

If you don't trust the host you develop on then everything produced on that host must be audited by a trusted host. Maybe that works in environments where cost is not an issue, but I would be somewhat skeptical of any environment which attempts that without the appropriate resources. It also doesn't help in situations where source code disclosure is an issue (eg a dev posting too much to pastebin/stackoverflow/inadvertently searching google for paste buffer full of data etc).

There's no reason it can't work in say development environments - the simplest approach is to configure whitelisted directories which permit execution in most solutions. It's not perfect but it helps prevent execution of questionable downloads / attachments.

Client machines WITH credentials has to be made untrusted.

Network segregation is better if you truly care about security and costs in productivity. I think you'll find higher end environments have a 'trusted box' and a 'development box' which physically sit side-by-side on different networks.

I hugely agree on a lot of your points.

I'll also add that once I'm on a traditional network, ripping through active directory is generally not difficult - my first ever live pentest went from privileged non-AD asset to domain admin within about 4 hours. My average time to compromise has come down significantly since then, too.

There's lots of bad/scam security focusing on logging and monitoring, weird antivirus products and securing the wrong things. The last network I compromised dropped an obscene amount of money on a SIEM product that couldn't detect nmap or PtH attacks, I achieved complete compromise with the same chain of attack as my first ever pentest because nobody had looked at the fundamentals of implementation/configuration security.

If I could list things that would actually secure traditional networks:

- Application Whitelisting (Binary executables, strong macro group policies, browser plugin whitelisting).

- Active Directory Hardening (See: ADSecurity, Microsoft AD Hardening Guidelines, ACSC Windows 10 Hardening Guidelines)

- Regular Patching and reliance on Microsoft Products (they're actually pretty good!)

Dunno if you'd consider these 'zero trust', but unless you've covered the fundamentals nobody is going to waste time figuring out how to abuse your network with speculative execution or drop a huge amount of budget to develop a perimeter breaching RCE 0day. Especially when in most cases sending shitware.docx.exe to a sales staff member (who is almost always going to run whatever you send them if there's a bonus incentive) will suffice.

Just because the primary key is gone doesn't mean other data can't be cross referenced. Birth dates with external sources, addresses with public registers, etc.