PortSwigger Research

>Also CORS and SOP can be bypassed: https://dev.to/pssingh21/websockets-bypassing-sop-cors-5ajm

Like I said, you can reimplement SOP by checking that the Origin header equals the Host header. Or alternatively check them against an allowlist. It's just a couple lines of code, and then it's as secure as normal HTTP.

https://dev.to/pssingh21/websockets-bypassing-sop-cors-5ajm

That article contains a confusing quote:

>The initial handshake occurs via HTTP Upgrade request, the response body is disregarded and the HTTP/HTTPS protocol is upgraded to WS/WSS protocol.

But the response body isn't disregarded. What could best be described as the response body is the server->client websocket messages. Those aren't disregarded.

>Even very experienced teams make mistake with this kind of things. See for instance, this Kubernetes vulnerability: https://goteleport.com/blog/kubernetes-websocket-upgrade-sec...

Thanks, that's an interesting vulnerability. I'm not so sure it's websocket-specific though. It looks like the attack could be done without websockets at all. The end request that does the malicious action is plain HTTP. The initial request that triggers the desync uses a Connection: Upgrade header, which is used in websockets, but isn't actually websocket-specific. Connection: Upgrade was created in RFC 2616 from 1999, which was before the websocket RFC 6455 in 2011.

The vulnerability was there was a proxy, and the proxy didn't properly handle the Connection header as specified…

Does obtaining Global Entry minimize the chance of them deciding to harass a citizen crossing the border, I wonder? It is at the cost of your biometric - but data on your devices might be worth more, and as I note elsewhere in this thread, you can image a computer and back it up fully, but not a phone without some data loss, unfortunately. [ TWRP possibly can do it right perhaps, but it requires unlocking the bootloader (which wipes the phone), and once bootloader is unlocked, it's more vulnerable to Cellebrite and company, to my understanding, ]

seeing the latest (leaked?) Cellebrite info from 2024 Summer- BFU State[Before First Unlock state] after posting on, modernimoPuxelsiPhones on the latest OS, and graphene devices see moto be the hardest to get into.

Anyway- , with computers - this was a solved problem from a technical standpoint- Yes I'm talking Truecrypt then, and today Veracrypt. The Hidden Container feature is impressive- but the Hidden OS feature allows for a truly hidden OS behind the scenes that can't be found at all. However, there's a unfortunate weakness that makes this hard to use today- it's limited to MBR , not UEFI [GPT]systems- so unless you like your computer not being able to have more than 2 Tb - and only 4 partitions (so good luck If you do a lot of stuff from dualbooting to other whatnot) We need a Veracrypt Hidden OS equivalent for UEFI systems that's truly undetectable.(That also will work for Linux and maybemeMac not just Windows as…

Bit of a rambly reply:

There are different types of web security vulnerabilities and the attacks you see from automated scanners are likely to be far less sophisticated than targeted web attacks. Specifically these scanners are going to spam out widespread and common CVE's that might grant privileged access to the server or dump credentials in some fashion.

The more sophisticated attack you described is essentially an overflow, and most modern web servers are usually written in memory-safe languages making it very unlikely to see that type of attack on the web. More often it's the underlying OS, servers, or communication stacks (bluetooth, TCP, nginx, etc) that have these types of vulnerabilities since they are often written in low level non memory safe languages like C and C++.

Attacks that exploit the HTTP and HTTPS protocol are a little more interesting. Request smuggling lets you trick certain load balancers and webservers by sending an HTTP request "smuggled" inside of another HTTP request.

Here is a blog by James Kettle's about some request smuggling vulnerabilities and the impact they can have. https://portswigger.net/research/http2

There's really a lifetime's worth of knowledge on web security and the type of stuff you see in scans is just trying to hit the low hanging fruit. Portswigger has loads of free challenges and information about different web security topics.

https://portswigger.net/web-security/all-topics

If you're a small startup looking to automate security testing against your application, I strongly recommend just shelling out for Burp Suite; it's like a couple hundred bucks tops, can be used to automate almost every common web app attack, and is the tool most likely to be used by good auditors when you eventually decide to get tested professionally.

http://portswigger.net/burp/

There's a free version, which disables the (mostly vestigial, anyways) "scanner", and slows down the fuzzer tool; if you're really automating security testing --- which, do --- pay for the real version; you want the fuzzer to work.

There are things sqlmap does that Burp does not do easily, but they're not important to app developers; if you're generating database exceptions with inputs, don't dick around trying to make time-based blind SQL work; just fix the bugs.

A bunch of great answers.

I've been in offensive security for ~10 years now and am a staff at one of these billion dollar SV tech companies now.

If you want to do pentesting (though i prefer the team offensive security) my advice is to learn the basics of web app security with something like portswigger's course https://portswigger.net/web-security.

Since most tech is really API's and web apps this course would be able to get you productive and probably a jr level skillset. OSCP is also good but I find network hacks are not as applicable today thanks to the cloud, though the thinking process and creative puzzle solving could be worth it.

I would particpate in as many CTF type challenges as possible (http://www.xssgame.com) then apply to jobs. Make it clear you are a junior but good at Burp and web testing.

Good luck!

Application Security Engineer here.
For a developer I would recommend the OSWE certification which takes a more code-centric approach and resources such as https://portswigger.net/web-security and The Art of Software Security Assessment book. You can also leverage your DevOps experience for learning about server, app and cloud misconfigurations and their impact on security.

The demand for network security is not as high as for appsec people and I personally don't see network security as very rewarding (intellectually and financially).

For the Pentesting route I recommend trying some HackTheBox and watching Ippsec's channel (https://www.youtube.com/channel/UCa6eh7gCkpPo5XXUDfygQQA).
OSCP is fine, but it is a beginner certification and definitely not enough for getting a Pentest job.