Android Tutorial [B4X] Tip - Modified server response

Discussion in 'Tutorials & Examples' started by Erel, Feb 27, 2019.

  1. Erel

    Erel Administrator Staff Member Licensed User

    While analyzing a Crashlytics crash report of a small app of mine I was surprised to see the following error:

    Fatal Exception: java.lang.NumberFormatException
    For input string: "<html><head></head><body><script type="text/javascript">try{if(parent.document.location==document.location) window.location="xxxxx"referer=&startm=201203";}catch(e){}</script></body></html>

    The app sends a request to a server implemented with B4J. The server responds with a number. The code looks like this:
    Code:
    Wait For (CreateJob(...)) JobDone(j As HttpJob)
           
    If j.Success Then
               SavedGroupInfo.GroupId = j.GetString 
    '<--- crash here
    The user internet provider modified the server response and returned a JavaScript that does something (it is related to "safe internet" feature).

    Bottom line is that even if you are calling your own web service you cannot assume that the server response will not be modified...

    BTW, I recommend adding Crashlytics to your apps. It provides more information than Google Play and the data is sent automatically.
     
    alwaysbusy, OliverA, Gunther and 4 others like this.
  2. Harris

    Harris Well-Known Member Licensed User

    Geezzzz...
    Was the response number wrapped up in the return somewhere?

    I use the same method all the time to update the record (with return ID) to SENT. If it doesn't get updated, it will continue to be sent - forever.
     
  3. OliverA

    OliverA Well-Known Member Licensed User

    Wow. How does this even make sense? So let's add some JavaScript to a return that had no JavaScript, since JavaScript is just so ridiculously safe (yes, that was sarcasm). BTW, I tried to search for this (wrapping HTTP returns in JavaScript), but could not find anything. Pointers would be welcome.
     
    Harris likes this.
  4. Erel

    Erel Administrator Staff Member Licensed User

    No. The original link was included. My guess is that the JavaScript sends the URL to the "safe internet" server and then redirects to that page. I might be wrong here.
    This of course doesn't work when the request is made outside of a browser.

    Search for JavaScript injection.
    Example: https://stackoverflow.com/questions/4113268/stop-mobile-network-proxy-from-injecting-javascript
    https://security.stackexchange.com/...ecting-strange-codes-to-every-website-i-visit

    SSL doesn't help as they install their own certificate.
     
  5. OliverA

    OliverA Well-Known Member Licensed User

    For some reason I was looking for additional JavaScript that helped with security and found no hits. The two samples listed show 1) ISP's injecting ads and 2) ISP's automatic bandwidth reduction scheme. The security aspect would be interesting to see, but I smell ... .
    I guess this incident really shows that one really needs to host their site (via VPS or otherwise), use their own certificate and process EVERYTHING over HTTPS. If anything happens with this configuration, then your dealing with an actual MITM attack.
     
  6. Erel

    Erel Administrator Staff Member Licensed User

    In this case SSL doesn't help. I've checked the ISP instructions (in Hebrew). They include installing a custom certificate authority. This is indeed a MITM "attack".
     
  7. OliverA

    OliverA Well-Known Member Licensed User

    In this case, I think they are injecting the JavaScript before the encryption. I could see that happening if it is a shared hosting system instead of a VPS. Of course, if they are doing that, they are totally cancelling out the benefits of a custom certificate authority. Now, if this is a VPS and this is still happening, then somehow the ISP has access to the VPS or they are really doing something clever here (not in a good sense though, since this would break the trust in HTTPS).
     
  8. Erel

    Erel Administrator Staff Member Licensed User

  9. OliverA

    OliverA Well-Known Member Licensed User

    That's the key though! Did the device that runs your "small app" do that? If it did not, the MITM should fail. Or is your app accepting all certificates? If so, that's defeating the purpose of HTTPS too. So if they inject JavaScript with a Proxy, it would break most accesses to the site, since I just can't see that everyone that visits that site just goes ahead and installs the Proxy's root CA. Now, I'm not contesting that deep pockets (state actor's) can't get around this by forging CA's, but in this case I'm pretty sure that 1) this is a shared web host, not a VPS and 2) that they are injecting the JavaScript before the encryption happens. BTW, I'm not picking a fight here, I'm just hoping to clarify some points, since if this were a true MITM (without having to install a root cert per device accessing the site) that is not discoverable when accessing the site via HTTPS and is capable of altering in-flight HTTPS content, we are having some huge issues here on the order of breaking the internet (the HTTPS portion).
     
  10. Erel

    Erel Administrator Staff Member Licensed User

    Yes. The customer is using an internet provider that provides a safe internet service. As part of this service they install a root certificate on the device. They install it once and this allows the internet provider to act as a man in the middle. The root certificate allows it to forge certificates of all sites.

    No.
    The app interacts with this server. It is a VPS with a valid certificate.

    Of course not. Don't worry :)
     
Loading...
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice