An Android application sends a request to "https://google.com". How would i
fake the HTTP response without an actual network request, using Frida?
I am trying to teach myself reverse-engineering, but I can't figure out how to do this.
The best way of doing that is redirecting the request to an address that you control and then return there a user-controlled response.
You will then need to find which methods to instrument related to the HTTP request itself and return valid data to the app.
Related
Some third party is sending an Http Post request whenever something changes in their DB (e.g. when a contact has been updated, they send the contactID and 'contact_updated'). I have build a socket listener that catches those requests and is able to parse the information. However, I just can't get it to work to send back a response with the status '200 - OK'. Thus, the server on the client side keeps on trying (four times or so) to re-send the request.
Is there any, simple way to just send the response status without the need of adding external libs etc.?
It should be enough to send the string HTTP/1.1 200 OK back in your socket-listener.
If you have troubles, you can check out this answer, it shows how to use a HttpServer in Java just via plain JavaSE features.
Use
response.setStatus(HttpServletResponse.SC_OK);
to set the status code in your response header.
You may also set the content type.
response.setContentType("text/html;charset=UTF-8");
Suppose I have a resource that is hosted on a websocket server, and I wish to validate the response status code 101, after the connection is upgraded, how and which libraries to use.
Im currently looking at jayway response library, when I connect to a websocket resource, initially it sends a 200 and then upgrades to 101. So code returns 200, I would like to know how this library can be used for websocket validation.
Sample code is :
String response =given().get()("https://www.ws.com:444/examples/websocket/snake.xhtml")
.getResponse().asString();
This returns a 200, but does not return the next response. I might sound a little rusty here, would appreciate if you folks have any idea how to extend it to get status 101 or if you have any other suggestions.
Also, this requirement needs to be extended to handle redirection 30x status codes as well, assume a resource is protected behind an access gateway, when a request comes for this protected resource, the gateway forwards it to identity store for verifying the user, at this time a 302 is returned, once verified, request is sent back to access gateway from where user is able to access websocket resource.
I'm using java.net.HttpURLConnection.
I first write the body of the post request to the OutputStream associated with the URLConnection object.
After I have done that, I close the OutputStream and then call getInputStream() or getResponseCode() or getHeaderFields(). That's when I find out if the provided credentials were considered valid or not valid.
This is problematic, because I don't want to make the same post request again (and have to re-upload its contents, which could include large files) in the event that the user credentials were rejected for some reason.
Since an exception is thrown if there is an attempt to call getOutputStream() after getResponseCode() or getHeaderFields() have been called, how can I ensure that the user credentials were accepted before attempting to upload the data?
Is there a way around this or is it just the way the server is configured?
The short answer is: You can't do that.
Basic auth is stateless. When you're doing a POST/PUT the user credentials are sent as headers for that HTTP request. They are not processed until the entire operation is complete (i.e. after you've sent the data payload).
In order to do what you're talking about you'd need to write a web service that managed login and file/data uploading separately through session management, allowing you to first authenticate (returning a session token of some sort) then send the data via a separate HTTP request.
Edit to add: In reality, you could hack your way around this by simply doing a GET to something that also requires auth. If it succeeds, you know the POST will also succeed baring the credentials being invalidated server side between the two requests. I would not advise this, but it would work.
I'm new to Java Servlet programming and have a question about how to handle POST response from other servers (not user's POST request) using Servlet programming.
Suppose my application needs to consult another server in order to process user's request. I need to
send an asynchronous POST request (i.e. specify a redirect_uri in the POST request body) to the other server;
handle the POST response from the other server;
present some result to the user.
I think I need one Servlet to handle user's request and send a POST request to the other server, and I need another Servlet (since the POST request is asynchronous) to handle the POST response from the other server. My specific questions are:
What's the best way to send a POST request in this case? For example, using HttpUrlConnection?
How to handle a POST response in a Servlet? It confused me because a servlet is supposed to handle "request" not "response" but in this case the incoming message is indeed a POST response from the other server. In particular, if you can point me the relevant API/method that would be really helpful. For example, in doPost()? How to get the POST response body? (I assume we can get it from HttpServletRequest object).
Thanks very much!
Yue
I did not understand the term 'POST Response'.However may be you are talking about servlet chaining scenario if I understood your requirement correctly.
Servlet Chaining means the output of one servlet act as a input to
another servlet. Servlet Aliasing allows us to invoke more than one
servlet in sequence when the URL is opened with a common servlet
alias. The output from first Servlet is sent as input to other Servlet
and so on. The Output from the last Servlet is sent back to the
browser. The entire process is called Servlet Chaining.
Example of Servlet Chaining
I want to access a full rest service with basic http auth running.
However there is no way to for the javascript browser client to suppress the authenticate box when a wrong credential is provided.
I thought about different methods to solve this problem
someone suggested to remove the WWW-Authenticate Header with a filter (i dont think this is a clean approach)
i could rewrite my app to not use Basic Http Auth at all (i think this is too much trouble)
i could write a proxy that talks to my regular service
I like the last approach the best.
I keep my regular Rest Interface, but also have the option to use this interface with clients that are not that flexible.
Furthermore I can later proxy Http Requests unsupported by some browsers.
The idea is to have a /api/proxy/{request} path that proxies to /api/{request} and returns a Facebook-Graph-like JSON query { data: {data}, error: {error}}
This is the stub of the Proxy class
#Path("proxy")
public class ProxyResource {
#GET()
#Path("{url: [a-zA-Z/]*}")
public String get(#Context Request request, #PathParam("url") String url) {
// remove proxy/ from path
// resend request
// verify result
}
}
I can access the Request (which seems to be a ContainerRequest). How can I modify the request without building it from scratch to resend it.
Edit: when somebody knows a better approach i am delighted to hear about it.
As I started to digg deeper into this, i found out that not the 401 was the problem. The www-authenticate header sent back from the server caused the browser to open the login box.
If somebody is interested I've written a little nodejs proxy to remove a www-authenticate from all server requests.
https://gist.github.com/ebb9a5052575b0a3f41f
As this is not the answer to my original question I will leave it open.