41–50 of 82 posts
Earlier quoted context omitted.
[flagged]
You can read SSL traffic if you're able to install a root certificate on your device and the website/app doesn't use certificate pinning. I recently used HttpToolkit to reverse engineer a REST endpoint that used SSL encryption
[flagged]
[flagged]
Seems like the proxy handles all the SSL, and likely strips any SSL Specific headers, etc..
But also, many, many, many companies do this exact thing. Just one example: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?...
This is a nice tool. A game I liked to play announced end of service back in 2023. They gave enough notice to let me capture some logs from their cooridinator service. I captured them in mitmproxy and ran those through this to help me identify all the endpoints and their general structure. (A few things were a misnomer, like the examples suggesting certain values were able to be floats when they could only be integer…
Amazing! What game was this for? I was involved in the RE efforts around UO way back in the day.
[flagged]
Modern TLS is great, but there are limitations on what it actually provides especially around the CA trust model. These mitm tools are not designed to take random traffic from the internet you intercepted, they require privileged endpoint access to enable specific debug features or configurations.
[flagged]
[flagged]
This is only a problem if a client application has a server certificate pinned in source code. Otherwise, you can create a cert with a privacy CA and add it to a desktop OS trusted cert store.
0: https://hugotunius.se/2020/08/07/stealing-tls-sessions-keys-...
I've used this tool in the past with success. Not perfect but it accelerates the work greatly if you can launch a mitm proxy quickly and are familiar with the tool. I've been fighting lately with an API, though. It's not very, let's say, RESTy. It has only one endpoint, and the different "sections" of the API are defined in parameters, so MitmProxy2Swagger doesn't detect them properly :(
To be fair, from what I understand an actual(tm) REST API would only have a single defined endpoint[1]: the entry point. With every other endpoint being discovered from the responses. And also from your message I'm guessing a URI still uniquely identifies a resource (specifically through the "query" part of the URI, instead of the more common "path").
So, technically, assuming there's nothing too weird with that API, it seems like MitmProxy2Swagger is failing to detect a REST API.
[1]: Corollary: If an API is RESTful, it should be possible to rename any endpoint (except the entry point) at any moment in time without prior notice, and clients would not break as long as the response types/schemas are still supported by the clients. In-flight requests might fail with a 4xx, but after a retry they should go to the correct endpoint without any code change required.
Again, this is the very easy part of the reverse engineering API process that most tools can do, similar to API Parrot and the rest of them. This is not hard to do. The hard part is that inevitably, all these internal APIs will just add aggressive CAPTCHAs, Device Check, fingerprinting, etc to prevent common drive by re'ing. Easy to add these on the defence side, and extremely difficult to bypass on the other side. I…
I've used this tool in the past with success. Not perfect but it accelerates the work greatly if you can launch a mitm proxy quickly and are familiar with the tool. I've been fighting lately with an API, though. It's not very, let's say, RESTy. It has only one endpoint, and the different "sections" of the API are defined in parameters, so MitmProxy2Swagger doesn't detect them properly :(
> It's not very, let's say, RESTy. It has only one endpoint, To be fair, from what I understand an actual(tm) REST API would only have a single defined endpoint[1]: the entry point. With every other endpoint being discovered from the responses. And also from your message I'm guessing a URI still uniquely identifies a resource (specifically through the "query" part of the URI, instead of the more common "path"). So, t…