I was told that it was easy but people to view the contents inside the $_POST[] array, is it really that easy? How do hackers do this and how do I prevent it? Should I start storing more items in the SESSION[] array instead?
POST[]ing Extra Values
The POST array is populated entirely by data transmitted from the client and everything inside it should be suspect. So don't take a number out of a postback request and set someone's account balance to it.
Also, "POST" is just a type of HTTP request, which means it's sent in plain text. Don't ask clients to send you login passwords over POST unless you wrap the HTTP stream with SSL (use https:// and configure your webserver properly) because you don't control the network between the client and your server. Major websites often don't do this (for performance reasons) but all online banks have done this for at least 10 years.
Think that POST data are sended from the browser with the HTTP request in plain text.
People that can snif your network or execute a Man in the Midle hack, can view this.
With a firefox extension like Tamper Data, the user can change the POST data before sending it to the server.
Never thrust POST data, always validate it in the server side.
From my comment on your earlier question:
A hacker can see the fields and values that are submitted through your form using easily available software tools, and then re POST them as he/she wishes.
Regarding MD5:
md5 isn't an encryption algorithm, it's a hashing algorithm. It'll turn any string into a 16-byte hash. In theory:
If you have two objects, a and b, and md5(a) == md5(b), then a == b
If you have md5(a) you can't figure out a.
These are the implicit assumptions when working with hashes, although they're never actually true - number one is clearly not true because if you hash 2^16 + 1 different strings then by the Pigeonhole Principle there must be two different strings with the same hash. The second one is also obviously not true because an attacker can search the range of md5 values for the hash, although for modern cryptographic-secure hashes (not md5) this is infeasible.
Getting to your question, you could just ask the client for the md5 hash of the user's password (you'd need client side javascript to calculate this) but that's a terrible idea. If all you expect from the user is the md5 of her password, then that's all an attacker needs to know, and you're sending it in plain text. What you could do is send the client a nonce. This is like a challenge. For the client to prove she knows her password, she can send you a hash of the nonce and her password concatenated. The idea is that any attacker can't answer the challenge becuase he only knows the nonce, and after the nonce-password hash is transmitted it's too late for him because you've already received it and aren't expecting an answer to that nonce again. Property 2 ensures that he can't extract the password from the hash.
This is vulnerable to the attacker stealing the challenge response and getting it to you before the client does. You can have a lot of fun making up a whole cryptosystem with multi-round communication (counter-intuitively it's actually possible to send hashes back and forth and securely authenticate) but soon you're just implementing HTTPS which someone else has already done for you :)
Related
I want to send a secret to a server, say the domain the current browser is visiting, but I don't want the server to know what the website address is, only if the server has a matching record for this specific domain.
I was thinking of simply hashing the domain-name on the client, and using then comparing hashes on the server, but in my late night of thinking, so to say, I can't think of a way to prevent the server from using the same hashing algorithm to "reverse" or "brute force" it's way to the answer.
So say the server was compromised, it has a hashed value + an identifier such as an IP. Now it could simply brute force all the dirties websites in the world, to see what website would return the same hash.
I was thinking of SRP (Secure Remote Password) -- not sure if that would make any real difference in this case.
Good night.
The typical process of creating a a new Parse user does not allow for server-side validation or any sort of input requirements. These can be implemented on the client-side but can be easily circumvented by anyone willing to try.
So how would someone provide a Sign Up where the fields are checked against different requirements (defined by regex) in cloud code?
Two possibilities I see immediately:
An extra method that takes in all inputs as parameters, checks against regex, on success continues to Parse.User.signup() then returns session key and assigns it to the device that just signed up.
Parse.Cloud.beforeSave(...) before the user is saved you check the fields, and reject if it doesn't pass a test.
Problems I see with each:
EVERYONE with my AppID and a client ID can call this method. Since the checks are being done server side there's need for additional filtering client-side which can be overwritten; an adversary could flood my Parse app with requests or bloated inputs. Also you are then sending the user's password over the network.
The password is encrypted upon user creation(setting password), according to documentation I've read. Everything but the password can be checked against a regex.
I'm sending password that user inputs to the server without obscuring it. I've read some suggestions to do the following before sending the data:
Ask the server for a seed value (a salt) using an ajax request
Hash the password + seed using a sha1 sum
Are these steps really enforce security in any substantial way? The salt isn't going to be unique so everyone can get it. The algorith of applying the salt is available to everyone as it is applied on a client. The algorithm of sha1 sum is also available so anyone can use it to unhash the password. So what's the benefit?
As far as I know these steps (Digest auth) the salt is unique for every session, so every login attempt will get its own, different salt. Please consult your sources if it is the case there, too.
The client, after reading the salt for the current login process and sends the hash of the password+salt to the server wich compares it to its own hash of password+salt.
Brainstorming request
I need an idea for an authentication algorithm with some unusual requirements.
The algorithm would be used to verify that the sender of a message is legitimate.
Restrictions:
The "transport layer" is e-mail
the sender ('Alice') is a human being
Alice only has access to a web browser and internet access (including a webmail account) as her tools; therefore she can't do very complicated calculations
The receiver ('Bob') is a computer with no direct access from the internet.
Bob has an email account that it checks periodically.
Bob can send email.
No sending info to a 3rd party: Alice and Bob can't send any out-of-band info. Reading some publicly available info (such as the time from a time server) is ok.
Assumptions:
Alice can access some information locally: maybe she carries a notebook, or we could even assume her web mail account is hack-proof, therefore sensitive information can be stored there.
Alice and Bob can exchange sensitive information directly at a time prior to the authentication (private keys?)
Non-goals:
encoding of the actual payload of the message is not necessary.
speed/latency are not (big) issues
Some ideas to get you started:
Plain old hard-coded password.
Problems:
brute force attack (not likely)
eavesdroping possible if the communication is done in clear text, then replay attacks possible
Simple algorithm based on current date/time
Example: Alice adds the current date, hour and minute and sends the result as the auth token, which Bob can verify. Let's assume that read-only access to a time server does not violate rule #7 (no 3rd party).
Problems:
security through obscurity: the algorithm is somewhat safe only because it is not publicly available (well, it is now... oops!)
Some sort of challenge-response mechanism - Alice sends a request for authentication, Bob replies with a challenge, Alice sends the expected response and the actual payload.
What are the details of the mechanism? I don't know :)
What can you think of? I'm hoping to see some creative answers ;-)
Edit:
Maybe an example would make rule #3 clearer: let's assume that Alice is using a proprietary closed-source device <cough> iPhone <cough> to access the Internet, or she is standing in front of a public internet kiosk.
My idea of a human-friendly low-tech challenge-response mechanism:
Bob changes the challenge every time he receives a valid message (for example he makes a salted hash of the current time)
every invalid message sent to Bob makes him reply with the current challenge, so Alice can query him by sending an empty mail
once Alice knows the challenge, she goes to https://www.pwdhash.com/
in "Site Address" she enters the current challenge
in "Site Password" she enters her personal password (which is known to Bob)
PwdHash generates a "Hashed Password"
Alice writes a message to Bob, using the hash just created as the subject
Bob receives the message, hashes the current challenge and Alice's password according to the PwdHash algorithm, and sees if his result matches the message subject
if it does, Bob accepts the message and and sends out a confirmation containing the new challenge (essentially this is step 1)
Advantages:
cheap & simple, may even run on reasonably modern mobile devices
human friendly (no math, easy to remember, prerequisites easily available on the net)
no replay attack possible
no clear text passwords over the wire
does not run out of passwords (like one-time pads do)
no inherent time limits (like RSA tokens have)
the PwdHash web site can be saved on disk and called locally, no third party dependency here
Disadvantages:
Bob and Alice must pre-share a key (Alice's password), therefore Alice cannot change her password off-site
compromising Alice's password is the easiest attack vector (but that's the case with almost all password protected systems)
Note that PwdHash is an open hashing algorithm, Bob can easily implement it. The PwdHash web site works without post-backs, everything is client side JavaScript only, no traces left behind.
Two options I can think of:
Issue a card with one-time passwords (communication before the fact, notebook)
Electronic device that produces pincodes (avoids replay-attacks)
In addition to Treb's answer, you can use one-time passwords you can print instead of SecurID. See "Perfect Paper Passwords" for details.
Am I missing something obvious in suggesting a simple public/private key and signing the email?
Firefox has at least one extension to allow GPG in webmail.
Elaborating on lassevks answer:
In my company we use SecurID tokens from RSA for remote authentication.
It gives you a 6 digit number that changes every 60 seconds as an authentication token, supposedly your token generator and the server are the only ones in the universe which know the token that is valid right now.
As a low tech alternative, a set of n (10, 20, 100 - whatever is reasonable in your specific case) one time authentication codes can be given to Alice. I would ask her for a specific code (e.g. number 42 in the list). After using this code, it becomes invalid for further use.
Edit: See lacop's answer for a good implementation of the low tech solution.
Consider to create a web page which contains the algorithm as JavaScript, possibly as a download (so she can download it once and carry it along on an USB drive).
The idea is that she opens the page, checks the source code (all JavaScript must be inline) and then enters her password in a text field on the page. The JavaScript will translate this into a code as she types (so no network traffic while she does this; if there is, there might be a keylogger running in the background).
After she has the code, she can copy it somewhere.
The JavaScript can use the current time as a seed. Slice the current time into five minute intervals. Most of the time, using the current time will be enough to decode the password and if you're close to the start of the five minute interval, try with the previous one.
See this site for an example: https://www.pwdhash.com/
If Alice can run code on her machine (for example by using JavaScript that is found on some public site, like: http://www.functions-online.com/en/sha1.html), she can receive the challenge, hash it together with the password, and send it back.
Here's another suggestion:
Start with the Diffie-Hellman key exchange, resulting in a shared private key, known only to presumably-Alice and Bob.
Have a pre-defined password known only by Alice and Bob.
Have Alice encrypt the password using the shared key and send it to Bob
Now Bob can see that presumably-Alice really is Alice.
Problems:
Diffie-Hellman is not safe using small numbers.
What would be a simple symmetric encryption algorithm (for encrypting the password)?
A simple way to protect data in transit without exchanging passwords is the three-way-XOR:
Alice creates a few bytes using her own key.
She XORs the data with these bytes to make them unreadable.
Alice sends the encrypted data to Bob
Bob creates a few bytes using his own key.
He XORs the data with these bytes.
Bob send the double-encrypted data back to Alice
Alice applies her XOR pattern once more. Now, the data is only encoded with Bob's pattern
Alice sends the data back to Bob
Bob can now decode the data with his own pattern
If you're not going to use PKI, which is far and away the best solution, try using a challenge-response system like CRAM-MD5 (although I'd suggest a different digest algorithm).
Your constraints make the implementation of a secure cryptographic system almost infeasible. Is there nothing you can do to change the transport?
The most simple solution is to make Bob periodically send mails to Alice's mail account. When she needs something from Bob, she has to reply using one of these mails. Bob can put some check tokens into the mail (mail ID, or a string which must be repeated in the subject or body of the mail).
Just like many of the email verification schemes work.
Drawback: this only proves that the attacker has access to Alice's mail account, not that it is in fact Alice herself. To solve this, you could tell Alice a password and use the "JavaScript HTML page" trick so she can encode the key from Bob using her password.
This would prove that she has access to her mail account and that she knows the password.
There are several methods I can think of:
Install a https encrypted service similar to:
http://webnet77.com/cgi-bin/helpers/blowfish.pl
or
http://cybermachine.awardspace.com/encryption.php/
Or you could issue one-time passwords in combination with a XOR encryption
Or you can write a simple Java App (if Java can be executed in the machine) that can be loaded via www and provides public key encryption.
Hmm... would this count as a thrid party?
Set up a brother of Bob - Charlie, who is accessible from the internet via HTTPS. To send a message to Bob Alice would first have to log on to Charlie (via plain old password) and then Charlie would give her a one-use token. Then she sends her email along with the token to Bob.
Several of my ajax applications in the past have used GET request but now I'm starting to use POST request instead. POST requests seem to be slightly more secure and definitely more url friendly/pretty. Thus, i'm wondering if there is any reason why I should use GET request at all.
I generally set up the question as thus: Does anything important change after the request? (Logging and the like notwithstanding). If it does, it should be a POST request, if it doesn't, it should be a GET request.
I'm glad that you call POST requests "slightly" more secure, because that's pretty much what they are; it's trivial to fake a POST request by a user to a page. Making it a POST request, however, prevents web accelerators or reloads from re-triggering the action accidentally.
As AJAX, there is one more consideration: if you are returning JSON with callback support, be very careful not to put any sensitive data that you don't want other websites to be able to see in there. Wikipedia had a vulnerability along these lines where the user anti-CSRF token was revealed via their JSON API.
All good points, however, in answer to the question, GET requests are more useful in certain scenarios over POST requests:
They can be bookmarked
They can be cached
They're faster
They have known consequences (assuming they don't change data), so visiting them multiple
times is not a problem.
For the sake of posterity, updating this comment with the blog notes re: point #3 here, all credit to Omar AL Zabir (the author of the referenced blog post):
"Atlas by default makes HTTP POST for all AJAX calls. Http POST is
more expensive than Http GET. It transmits more bytes over the wire,
thus taking precious network time and it also makes ASP.NET do extra
processing on the server end. So, you should use Http Get as much as
possible. However, Http Get does not allow you to pass objects as
parameters. You can pass numeric, string and date only. When you make
a Http Get call, Atlas builds an encoded url and makes a hit to that
url. So, you must not pass too much content which makes the url become
larger than 2048 chars. As far as I know, that’s what is the max
length of any url.
Another evil thing about http post is, it’s actually 2 calls. First
browser sends the http post headers and server replies with “HTTP 100
Continue”. When browser receives this, it sends the actual body."
You should use GET where you're doing a request which has no side effects, e.g. just fetching some info. This request can:
Be repeated without any problem - if the browser detects an error it can silently retry
Have its result cached by the browser
Be cached by a proxy
These things are all good. Anything which is only retrieving data (particularly public data) should really be a GET. The server should send sensible Last-Modified: and Expires: headers to allow caching if required.
There is one other difference not mentioned by anyone.
GET requests are passed in the URL string and are therefore subject to a length limit usually dependent on the browser. It seems that most are around 2000 chars.
POST requests can be much much larger - in fact not limited really. So if you're needing to request data from a web server and you're passing in lots of parameter information then a POST request might be the only option.
So, as mentioned before really a GET request is for requesting data (no side effects) while a POST request is generally used for transmitting data back to the server to be stored (with side effects). e.g. Use POST to upload a file. GET to retrieve a file.
There was a time when IE I believe had a very short GET URL string. Some applications like Lotus notes use large numbers of random characters to represent document id's. I had the displeasure of using another product that generated random strings so the page URL was unique each time. The random string was HUGE... and it didn't always work with IE6 from memory.
This might help you to decide where to use GET and where to use POST:
URIs, Addressability, and the use of HTTP GET and POST.
POST requests are just as insecure as GETs. The main difference is that POST is used to modify the state of the server application, while GET only requests data from it.
The difference matters when you use clean, "restful" URLs, where the URL itself specifies the resource, and the different methods trigger different actions on the server side.
Perhaps most importantly, GET is book-markable / viewable in url history, and searchable with Google.
POST is important where you don't want the event to be bookmarkable or able to be typed in as a URL - otherwise you (or Google crawling your URLS) could end up accidentally doing things like deleting users from your system, for example.
GET
POST
In GET method, values are visible in the URL
In POST method, values are not visible in the URL.
GET has a limitation on the length of the values, generally 255 characters.
POST has no limitation on the length of the values since they are submitted via the body of HTTP.
GET performs are better compared to POST because of the simple nature of appending the values in the URL.
It has lower performance as compared to GET method because of time spent in including POST values in the HTTP body
This method supports only string data types.
This method supports different data types, such as string, numeric, binary, etc.
GET results can be bookmarked.
POST results cannot be bookmarked.
GET request is often cacheable.
The POST request is hardly cacheable.
GET Parameters remain in web browser history.
Parameters are not saved in web browser history.
Source and more in depth analysis: https://www.guru99.com/difference-get-post-http.html