My friend and I are working on a program. This program is going to submit GET data to our webpage. However, we don't want users accessing the webpage any other way than the program. We can prevent users from sharing the program using HWID authentication, but nothing prevents them from using a packet scanner to get the URL of the webpage. We thought about user-agent authentication, which we will implement, but user-agents can easily be spoofed.
So my question is, how can we prevent users from accessing the webpage directly, instead of through the program?
Even if you don't have an answer that will completely work, anything that will help deter them would be nice.
Currently we will be implementing:
HWID Authentication to use the program
User-Agent Authentication to access the web page
Instant IP Blacklisting to anyone accessing the webpage without the proper User-Agent
Do not rely on user agent or any kind of browser fingerprint, HTTP headers are easily forged/spoofed.
You could add some secret token (eg. password/login) to the request and send it through SSL to prevent eavesdropping.
Or better, use an SSL client certificate.
Edit Are you going to distribute the VB program? If so, as bobince mentioned, there's no way you can prevent a determined hacker to forge requests. You can raise the bar but it will be security through obscurity. Even with client certs, the hacker will be able to extract the cert from your program and send modified requests.
As long as you accept requests from the client, these requests can be forged. Deal with it.
One option is you can set an encrypted token in the request header.
The Token can be used only for single time. If the same token is sent again the server will reject it, means u have to maintain the copy of utilized tokens on the server side.
one option is to use and verify a custom header which a web browser does not send, i did a similar thing for a program of my own. Do that ontop of the other verifications you are doing. On serverside, have your server script verify the custom header and simply redirect if the header is wrong
Try encrypting all ur webpages using the a long key(512bits or more) use the HWID as a salt.
This way only ur program can decode it and render it as a webpage.
en.wikipedia.org/wiki/Salt_%28cryptography%29
C# & VB.net here:
obviex.com/samples/hash.aspx
Related
I wrote a PHP application which requires a login. This application is private so no new users can register. First I used sessions to identify the users but it lead to problems on tablets because they lost their sessions. I think this is because of energy saving operations.
Now I changed my application to generate a random security token. So the authentication is as the follows:
Log in
Generate random security token and save it to disk
Redirect the browser to http://myhost/site?id=[securitytoken]
On the server side I check if the file exists - if yes, user is authenticated
Everything is now working perfectly I am just thinking about security concerns. It is no problem if the user sees the security token. Is it somehow possible to find out the token when I use GET? I am using SSL.
I tried to change the expiration times and cookie lifetimes. On a normal computer it is working as it should. On the table it is also working IF it does not go into standby (meaning the screen gets black). If the screen gets black, the session expires very soon.
There is no vulnerability inherent to using GET instead of, for example, POST from a network perspective.
The only caveat you should keep in mind is that a GET request is more likely to be stored on the client (e.g. browser history) in a way you might not intend. For these reasons, I typically use POST requests for authentication.
The problem you are attempting to solve sounds remarkably similar to "remember me" cookies. The linked blog post might be helpful in mitigating the security risks involved in designing token-base authentication systems.
Generally, web apps are confined to using localStorage and cannot silently read/write to files in the background. How are you accomplishing this?
When you say you're using SSL, do you really mean TLS or do you mean SSL version 3? If SSLv3, I would advise updating your stack and webserver configuration to support current best standards. TLSv1.2 with ECDHE and AES-GCM + SHA2 or ChaCha20-Poly1305 are ideal.
GET is more vulnerable than POST as it can be transmitted and stored:
In server logs by default.
In corporate proxy logs.
In the referer header if your page uses external resources or links to external domains.
In your example you have a http URL (this could be a typo though as you said you are using SSL). Make sure you are using https URLs to protect this data in transit.
This approach could also be vulnerable to Session Fixation as an attacker could get the user to visit a URL containing, or redirecting to, the same session ID as the attacker. When the victim logs in, the shared session will be authenticated meaning the attacker is now also logged in. To protect against this, refresh the session ID upon login and logout.
Cookies are often the preferred approach for session handling as they are harder to attack in the above scenarios.
The issue with in URL variables in the get form means that for one : users can easily modify it (by accident or not) and they stay even when the link is copied somewhere.
If you send someone your link/someone gets your link with the id variable in it,is that a security risk to you?
I have a file in PHP receiving a POST from an Android application and it works correctly but it also works correctly if loaded from a browser. What would be the most correct and efficient way to prohibit this from happening?
Try testing for the user agent in the request $_SERVER["HTTP_USER_AGENT"]. With PHP you can use the get_browser() for more information given the user agent.
Note that any client could send fake a user agent, so this information is good hint, but as any user input, it must not be trusted completely.
If you own the Android application I would suggest sending a security token generated on the android app via HTTPS to your PHP app where it would be validated.
Add header while making the HTTP request.
e.g. Application Type
httppost.setHeader("Application-Type", "ANDROID");
This will differentiate between your calls and server may get to know if call is made from mobile with having this header while Browser doesn't.
Take a look at a page with phpinfo() on that from the android
You can check the Browser and OS, based on that you can chose what to do
I'm using loadVars to load a PHP URL with lots of sensitive information required for the Flash application. Only problem is that URL can be accessed via a web browser which raises security issues if someone gets a hold of this URL. Is it possible to have the PHP page only accessible via my Flash application?
Appreciate the help!
Thanks
No, there is no way to limit a page to a specific app, browser or user agent, since all of those things can be mimicked. If you are passing around sensitive information then you need to do authentication and use encrypted data transfer (HTTPS).
Regardless of how you attempt to make it only accessible from your Flash application, a determined user will certainly be able to view the page also. It can be as simple as proxying the requests through an HTTP proxy like Charles, Firebug or Wireshark.
There are things that can be done to make it more difficult to figure out what the data is from viewing the page directly. For instance, you can encrypt the data or output it as binary. But since SWF is an open sourced format, users can use decompilers or just inspect the ABC (Actionscript Byte Code) to see what is really going on.
The short answer is NO, you cannot protect the information available to the client side (Flash) from being accessible from other clients.
As long as you have a page on HTTP, a determined user can always find a way around any user-agent restrictions imposed by you.
One way to protect the data (other than using HTTPS) is to encrypt it at the server, send it over HTTP and then decrypt it in Flash using as3Crypto or some other cryptography library.
Hope this helps,
I learn that HTTP_REFERER or any HTTP request header can be fake and not reliable.
REMOTE_ADDR is reliable though.
so, how can I ensure the incoming HTTP_REQUEST call is coming from a website that I white-list?
For example, I have a js code that will send from client site to server. (something like a sniper, cross platform). however, I only allow this happen from several websites. Not others. so, even other people copy the code and put onto their website, it won't work.
In the general case you simply can't do it. You are entirely at the mercy of the client. You can make it more difficult by checking the referrer, but not impossible.
The only way to do this reliably is to have all those several websites generate unique tokens for every users, similarly as how you protect yourself from CSRF attacks. The tokens would then be sent along with the request by your script, and your server would need to have a way to check the token for authenticity against the other websites. Needless to say this is very likely impossible unless you control all sites.
See also this question on HTTP_REFERER
Haven't used this in practice, so there might be practicality issues I wasn't counting on, but thought I'd contribute the idea anyway. If I interpret correctly, this is similar to (if not the same as) the idea #Seldaek posted.
Your Server generates a unique ID for each page-serve and embeds the ID in the page.
Server stores the ID and the Client's IP address.
The js on the client places the ID in its request to the Server and sends the request.
When the Server receives the js request from the Client, it only responds if the IP/ID pair matches one that is on-file (see #2).
After some specified time (and/or when the browser session ends), the ID/IP entries expire.
This could perhaps be faked if a person sharing the visitor's IP address (perhaps both are behind the same NAT box) hijacks another visitor's session in real-time, but it will at least prevent someone from making another web page which piggybacks on your server's service.
There could also be issues if, for some reason, your visitor's IP address changes between when the page was served and when the js request was sent.
Basically, your server is saying "I will not service your js request unless you possess the data from a page I recently served and you are coming from (to the best of my knowledge) the place to which I served that page."
All http headers can be faked.
If you are just accepting communication from the remote server (and not having a client browser be redirected to your server) then you can either set up a VPN between that remote server and yours or you can change your firewall config to only allow communication from a specific set of IP addresses. However, even the later can be faked by people willing to go that far.
If the client browser is the one either being redirected to your server or loading the file(s) from your server then there is absolutely nothing you can do.
As #Billy says this simply isn't possible, you're thinking about the internets' request response mechanism incorrectly.
For example, I have a js code that
will send from client site to server.
(something like a sniper, cross
platform).
I assume what you're saying is that you have some javascript code served up on some website on your 'whitelist' which redirects the user to your website. Its on your website that you want to check that the user came from the 'whitelisted' site?
Aside from setting a cookie (might not be possible - cross domains) you might find it tough. Have you taken a look at OpenID? If you can post more details a solution may be more obvious.
so, how can I ensure the incoming
HTTP_REQUEST call is coming from a
website that I white-list?
I think if you sign every request(from whitelist) which is valid for that request only(once). I assume using uniqid for this is safe(enough?).
How would you use https ?, would sending information via GET and POST be any different while using https ?
Any information and examples on how https is used in php for something simple like a secure login would be useful,
Thank you!
It will be no different for your php scripts, the encryption and decryption is done transparently on another layer.
Both GET and POST get encrypted, but GET will leave a trace in the web server log files.
HTTPS is handled at the SSL/TLS Layer, not at the Application Layer (HTTP). Your server will handle it as aularon was saying.
SSL and/or HTTPS is used to provide some level of confidentiality for data in transit between the web users and the web server. It can also be used to provide a level of confidence that the site the users are communicating with is in fact the one they intend to be.
In order to use SSL, you'll need to configure these capabilities on the server itself, which would include either purchasing (an authority-signed) or creating (a self-signed) certificate. If you create your own self-signed certificate, the level of confidence that the site is the intended one is significantly reduced for your users.
PHP
Once your webserver is able to serve SSL-protected pages, PHP will continue to operate as usual. Things to look out for are port numbers (normal HTTP is usually on port 80, while HTTPS traffic is usually on port 443), if your code relies on them.
GET & POST Data
Pierre 303 is correct, GET data may end up in the logs, and POST data will not, but this is no different than a non-SSL web server. SSL is meant to protect data in transit, it does nothing to protect you and your customers from web servers and their administrators that you may not trust.
Secure Login
There is also a performance hit (normally) when using SSL, so, some sites will configure their pages to only use https when the user is sending sensitive information, for example, their password or credit card details, etc. Other traffic would continue to use the normal, http server.
If this is the sort of thing you'd like to do, you'll want to ensure that your login form in HTML uses a ACTION that points to the https server's pages. Once the server accepts this form submission, it can send a redirect to send the user back to the page they requested using just http again.
Just ensure you're sending the correct headings when allowing files to be downloaded over ssl... IE can be a bit quirky. http://support.microsoft.com/kb/323308 for details of how to resolve