Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
How can php be used to determine whether the connection used by the user is secure (e.g. via a VPN), as shown in the picture?
Click here to see the example img
TIA
Theoretically, no way to do this.
Practically, you could decide which VPN providers you define as "secure", find out the IP ranges that they use and check the source IP address of each request against that set of IP ranges.
A better way would be to think about security a bit more in-depth. From a theoretical standpoint, security can be thought of as a combination of confidentiality, integrity and availability guarantees for your service and the information it processes. You'd have to ask yourself if a user's VPN strengthens any of those guarantees.
For example, to protect information in transit between your clients and your service, it may be sufficient and more practical to serve all of your protocols over TLS (e.g. HTTPS for web services).
If your goal, for whatever reason, is to protect the confidentiality of a user's IP address, there is no way to enforce that. If your user chooses to use an IP address that should never be seen sending anything to your service, there is no way to stop that if your service has a publicly-routable IP address. There is a way for you to ignore or refuse that traffic, but anyone on the route between the user and your service can see the source and destination IP address in plaintext (that is, unless you use something like Tor [see https://en.wikipedia.org/wiki/Onion_routing ]). Largely, none of this should be applicable to any practical application.
At the end of the day, you should ask yourself different questions as to what information you are protecting, what kind of attackers you might expect, and what your application's attack surface looks like. Identify potential risks, evaluate their priority and implement controls to contain the risks. And remember that you'll never be able to eliminate risk completely.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 months ago.
Improve this question
I'm fairly new to coding, and when I try to find a way to lock my website behind a username and password field, every tutorial just hides them as a plain variable in some random file. I'm wanting to make the website only accessible once a username and password have been entered, but I want the usernames and passwords to be made and managed by myself, so only people I know can access it. If this is a really obvious thing I apologise, but if it's something that I can specifically look up please let me know so I can do more independent research.
There's no good way to do this on the frontend alone.
every tutorial just hides them as a plain variable in some random file.
Sounds like some pretty shoddy tutorials. Anyone could look at the source code of the site and get in.
The right thing to do would be to:
Hash the passwords (one-way encryption so that the original password text cannot be recovered, even if someone gains access to the hash)
Save the passwords in a database or (if there aren't many) in environment variables on your server
Set up routing on the server so that if the user isn't authenticated, none of the protected content gets sent to them in the first place - redirect them to the login page. (Don't serve the HTML of a protected page and then try to do validation from that page; with that approach, users would still be able to open up the developer tools and bypass your restrictions, by inserting their own code and removing your own).
Anything on the client-side can be tampered with and bypassed; gate requests behind the server instead, which is (or, has the potential to be) much more secure.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
How do services which have JavaScript client libraries secure those libraries and the APIs they call? Specifically:
Ensure library is only loaded on valid sites.
Ensure a user doesn't just open up the console and start making calls.
Any other major considerations to be made?
Ensure library is only loaded on valid sites.
You can't and you don't. Security in client-side JS is futile. If you're talking server-side JS, you're pretty much pwned if arbitrary code is able to execute server-side.
Ensure a user doesn't just open up the console and start making calls.
Most services require some form of API key/token, a value that needs to go with your API requests so that the service can check its validity. This value is usually only obtainable by being a registered user of the service. That means an API key is tied to an account. If the service finds out that you're breaking ToS, they can simply block your API key or account altogether.
For public APIs, there's a combination of rate limiting, tracking and blocking (i.e. IP or a fingerprint of some sort), referrer checks (ensure something is only loaded by a certain page, not somewhere else), UA checks (ensure a browser is downloading, not a bot, app or something), and more. Individually, these checks are easily spoofed, but combined, can be a deterrent.
Well, since your js basically lives client side then the only thing you could really do there is make users authenticate before they can really get your libraries. Anything past that would really just be a tiny roadbump to anyone who really wants to manipulate your js.
Where you do have and can maintain control is securing your API calls. The most popular forms are with basic auth, OAuth, and IP whitelisting.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I'm trying to make my REST API more secure. For the moment I'm hashing my password in my angular app with CryptoJs.SHA256 before sending it to my C# backend. But I realize it's better to hash password on server side. So how can I send a password only readable by the server? I'm going to add SSL but I know HTTPS is also breakable. Is there an other solution?
Thanks
As Bruce Schneier says, "Anyone can design a cipher that he himself cannot break. This is why you should uniformly distrust amateur cryptography, and why you should only use published algorithms that have withstood broad cryptanalysis."
While nothing is 100% unbreakable, breaking HTTPS is significantly harder than breaking a homecooked security scheme made in JavaScript. Consider this: if you serve your super-secure JS over an untrusted (HTTP or HTTPS-with-invalid-certificate) connection, what prevents the attacker from substituting a broken version, which will bypass all the JS security? Nothing.
Modern browsers are going to great lengths to prevent HTTPS from being broken (with HSTS etc.); so it's significantly safer to rely on HTTPS (which can provide actual security when used correctly - "just ignore all those big red errors" is one simple way to break it) than on JS-over-HTTP (which only provides a feeling of security without an actual chance of being secure).
Further reading: https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/
https://security.stackexchange.com/questions/3921/why-do-some-people-really-hate-security-via-client-side?rq=1
https://security.stackexchange.com/questions/8596/https-security-should-password-be-hashed-server-side-or-client-side
There are a lot of sources out there on this topic, but few have actually analysed it. As a general rule, trust guidance from Thomas Pornin more than anybody else. I also highly recommend my own survey and recommendation on the topic.
Not exactly a fullblown answer to your question, but i'd start by looking into using a KDF (Key Derivation Function) rather than just hashing your secrets. Some KDF libraries that you can look into are:
PBKDF2
bcrypt
scrypt
https://en.wikipedia.org/wiki/Key_derivation_function
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I have a website and am making a login system using cookies so the user can stay logged in, which I believe you can't do with sessions. I wanted to know if a malicious user could create or modify the existing cookies on the domain. I know they can delete them, that's fine, but can they create or modify them?
Anyone can control their browser, however they like. They can create, edit and delete cookies.
For that reason, your cookies should be long and random (or at least random-looking to the point of being indistinguishable from random).
They should be meaningful to your server, which should be able to relate them to a user, but not meaningful to anyone outside your server. They should be long enough and complex enough that guessing one would be statistically impossible.
Your server should be careful not to make any assumptions about the cookie values it receives. For instance, I could submit a cookie with 2,000 characters in it - that mustn't cause it to crash.
You can create, delete and edit your browser cookies, everyone who have access to your computer can read them, and copy so you can steal session ID for example.
You cannot modify session manually, because this is "server cookie", only server software can do it. If you want store password or other secret information, you should not store it inside cookie. Its insecure, you can store token or session id but not inforamtion like password.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I want to insert a piece of javascript in the clients websites to track various statistics (like crazyegg, intercom.io), but traffic related.
I was thinking of using IronMQ but I don't know how to call it from Javascript directly and I am affraid that making a request to my server (3Gb Ram) from sites that have tens of thousands of visitors / days can cripple the server when making too many javascript requests in the same time.
You can call the IronMQ thru the HTTPS API.
See IronMQ REST/HTTPS API for more information.
Of course, you will need to provide Project ID and Token to JavaScript code. I suggest to encrypt Token before you place it into JS/HTML and decrypt on page load or before using the API.
Welcome Iron.io Live Chat even you will need more information.
Upd: For now it seems does not work. Because of Cross-Origin restrictions. But we're working on it, so, stay in touch.
You'll need to optimise as you go. If you find CPU is a problem, optimise for that. If you find memory is a problem, optimise for that, if bandwidth, etc etc etc. It all depends on
your requirements
your resources.
Optimisation is almost always the last step in the development process.
You might just have people include a 1x1 pixel image, you might have them include an iframe, or you might have them include a javascript file running off your server. Or you might have them include a javascript file on their server. More questions you need to ask yourself might be what information you want, what security issues are there, etc. If it's information for their purposes, then you don't need to worry about them forging it. Otherwise, you do.