BetterPHP

I'm not very experienced with MITM attacks so, a few questions if I may.

1. When using an API, is it required for both parties to have SSL for a MITM attack to be prevented? I believe I read somewhere that it was but I can no longer find it.

2. Follow up on number 1: If the party that is accessing the API does not have SSL, can the data being sent back to them be altered?

3. Can the returned content from file_get_contents(PHP) or cURL(PHP) be vulnerable to MITM? For example, if I allowed a user to access a file on my site to get the returned value, would the content be editable by the MITM? I believe this is the whole point of MITM attacks but no site I visited had a straightforward answer.

4. Follow up on number 3: Would this also be the case if SSL was used on my site? That being, would the content returned by editable by the MITM?

I'm not very experienced with these types of attacks either, but from what I understand they should be more or less prevented if you have SSL. It's not impossible to pull of an attack when only one party has SSL, but it's damn hard, and usually not worth it unless there's some really sensitive data being sent by your API.

I have read a few pretty detailed articles on this. I'll do my best to dig them up.

I'll be back

Thanks, and yes it is very sensitive. I've been trying to work on auto updating of scripts by letting the user request my site via an API and read code via a temp file. Looks like I'll have to do more research and/or scrap the idea and make update scripts that can be downloaded at the site.

Update: There's a way to download a remote file with PHP (I think?) that I can use. What I'm thinking is the user makes a request to my API. If it's legit, I open up the updated version, open a temp .txt file in it with a private key. If a person were to attempt a MITM attack, they would have to know the private key when the script opens and tries to match the private key. The only problem I see is distributing the private key. If I assign it on the first API request, maybe in installation, the MITM attack can happen then and they can change the private key. Then when the user goes to update, another MITM attack happens and they download malicious code. I know I can do it on my site when the user downloads it, but I plan on posting them on open source project sites. Any ideas?

A solution that comes to mind would be to have dynamically changing private keys generated from a set of variables provided by the user, like a session id and an ip address.
This opens up to spoofing, but only if the attacker can access both the private session id and spoof the ip address.

It's just an idea and it might be hard as hell to implement.

The harder it is, the more fun in my opinion Problem being that MTIM attacks can intercept any private key made before it reaches my server if I understand it correctly. I may have everything the opposite way. No matter. There wouldn't be a session id that I could make on another site and routers often cycle through IP addresses so it would basically be creating a self-DOS.

Brining up another issue, I've been looking around for about an hour on this with no luck. I'm not sure if remote downloads are susceptible to MTIM attacks in which they can download it as well? Why must there be such annoying vulnerabilities in the world...?

I'm not even sure how I would remote download and upload to the server haha. I'm not sure if file_put_contents(); can work remotely and not have to worry about permissions. I have all my files chmod'ed to 640 to prevent hotlinking. I guess the only way is to sign up for some free hosting and test it out

I haven't really read the replies, so I apologize if this is off-topic.

If you are using SSL (https://) on your site, then the content between the two computers is secure. If the information is somehow intercepted, it would take 2,000,000,000,000,000,000 (2 followed by 18 zero's) years to decrypt (source), and modifying the information would instantly invalidate the request, and the connection between the two original users would be closed.

You do not need to buy a certificate to benefit from SSL, you can self-sign if you'd like (though that could cause problems if the software, e.g. cURL, rejects the connection because of this).

If you're only worried about MITM attacks, SSL would solve your problems.

I would recommend dynamic keys, like maybe push a new key to the receiving server from the master server every few hours or days, just do it through a cron (if you want to be really fancy, you might want to do something with one time passwords).

May I ask what kind of data you are planning on sending between servers/people?

Thanks for the article I guess I should start down the intended path then.

I do plan to self sign or find cheaper certificates. $600~ isn't really in my budget for no source of income coming from the projects I'm working with. Even ads get cluttery and no one really wants to see them. The script is secure as far as I can see. That is, all the owasp vulnerabilities are covered. The only problem it seems is MITM.

Dynamic keys could be interesting. Maybe update it every 24 hours or so. One key recrypting could be broken easy if they download the script themself and figure out the method.

The information is secured code generated only for the split second of the request, then it is deleted. It is run through a 4-way encryption with a random custom key generated each API request, uploaded to their server, decrypted, and overwrites their files. It's basically an auto update ability so that users can update some of my open source projects without having to manually redownload and reinstall every time. The only reason I'm bringing this issue up now is because the API is almost done, and there is a lot of sensitive data that can be breached if the code can be altered when moved to their server. It would basically be like an insecure file upload that allowed any file to be uploaded.

Can you take advantage of checksums maybe? You create a hash of the updated file you send, and then you hash the file again once it reaches its destination, if the hashes are a mismatch, you throw the file in the bin before it has time to do any damage and then try again?

I believe that is the only surefire way of knowing that your file has reached its recipient without being modified on the way.

Took me a while to know what you meant You mean hashing the code inside the file, then checking the code on the user's server against it? I suppose it could work but since the user updating won't have access to the updated code before hand, the hash will have to be placed in the returned json which could, in accordance to the article, almost impossibly be updated. Interesting idea though. It should at least sway off the noobs. I'll finish the API and come again for help to spot any vulnerabilities. Read a post somewhere that said API abuse is reaching the top of the exploit list these days.

Yes that is exactly what I meant, sorry for being so vague

Did some more research and learned that self-signed certificates unfortunately are not secure as an attacker can create a certificate of their own for your server and acquire the secret key to decrypt the data.