PHP
My website is almost done, but i'm having some problems with security. Actually, i didn't have problems yet, but i need to prevent. For example, the login system, i'm using cookies/session for it. And as people answered here, cookies are easy to overcome, and it's vunerable.
What is the best way to do a login system, including the passwords and data security?
Also, i'm using cookies for write the names of the users on posts. For example.
(Pretending that the login was successful)
$Cookie = $_COOKIE['username'];
$Cookie = $FetchUserNameFromDatabase;
//Then, on posts to write the name of the user, from the cookie.
$DoPost = "INSERT INTO posts (username, message) VALUES ($Cookie, $AnyMessage)";
Is this the best way to write the users name on posts, from a cookie value (since after login, the name of the user is saved on a cookie)?
IF NOT, what is the best way to do it?
Thanks in advanced.
#EDIT
I forgot to ask. Also, what's the best way to prevent people do a lot of comments (mass-spam)? For example, i do a comment (or a vote, or whatever) and works fine. Then, i do another comment and it blocks me for some time and i can't comment again until this time expires. What's the best way to do it, or at least, what the major sites/forums uses to prevent it?
Thanks again.
Why don't you just use session ids? I'd implement a login using a https connection, then assign a sessionid, wich identifies the user against your db. For further reference you won't even need a secure connection anymore.
In case you want to identify a post just use somthing like "SELECT username FROM users WHERE sessid=" . session_id()
In point of view, you should only use cookie information when you perform an operation that DOES NOT change the state of your application; like displaying the User name in the top of a page.
However in every scenario that you application is changing its state like adding a new POST (in your example) you definetly must not trust the client cookies.
To answer "The best way to do it", it depends on what technologies your are relying on.
Edit:
To prevent mass spam you should use the cookie information and the request information the like IP address.
Related
I am creating a saas, software as a service site with django.
Due to the project requirements the users are inside schemas/tenants, for that im using the fantastic django-tenant-schemas app, one user can have accounts inside different schemas (they share username and password) ... i want to let the user move throught the different schemas they are in more or less freely ... for that i have created a view where the user can select on what schema he wants to be on.
When i use an application wide cookie session that is when i have the cookie setting as ".domain.ext" (django documentation) that works fine but its NOT the behaviour we really want for our application.
What we really need is to be able to have different versions of the app on different browser tabs.
So we have to set the cookie configuration to "domain.ext", then everything breaks because the original view is on one tenant and the next view (where the just logged user really belongs) is inside other tenant then the old cookie is deleted.
So the question is how can i programmatically set the cookie correctly on the new view so the user that really belongs to that tenat is still authenticated.
Or is there any alternative approach we could use for that? Any examples?
EDIT TO CLARIFY as demanded:
Person A belongs to 2 schemas SH1 and SH2 on both of them he has the same username and password.
On every password change the password hash is replicated on all the schemas they belong to so they dont have to remember specific passwords or usernames.
When the person is logged on SH1 the url will be sh1.domain.com when he is logged on SH2 the url will be sh2.domain.com
So lets say the person is now logged on schema SH1, he decides to switch to schema SH2, to be able to do that i need the user to still been authenticated so that view has to be on the SH1 schema, but then its redirected to the new schema force authenticating the user but since the cookie is set as domain specific (default django behaviour) when the user lands on the next url sh1.domain.com/whatever the previous cookie is deleted and thus he has to log in again to be able to access.
If I'm understanding correctly, you want the ability to have the behavior of a cross-domain cookie, but without actually using a cross-domain cookie.
The immediate answer that comes to mind is "well, use a cross-domain cookie". This is pretty much the vanilla example of a situation where you'd want to use use a cross-domain cookie. Engineering a complex solution so that you can avoid using the simple solution never ends well :-) Unless there's some other constraint in play that you haven't revealed, I'd start by questioning whether you shouldn't just be doing this the easy way.
However, assuming there is a good reason (and, frankly, I'd be interested to know what that is), the problem you're going to face is that browser security is essentially trying to stop you doing exactly what you're proposing. You want to know, from domain SH2, whether something has happened to a cookie set on domain SH1. That's exactly the situation that cookie security policies are designed to prevent.
The only way you're going to be able to work around this is to have a third party that can share knowledge. When user A logs into SH1, you do password authentication as normal - but you also post a flag somewhere that says "User A is now on SH1". When A logs into SH2, you post the corresponding flag. If A goes back to SH1, you check against the central source of truth, discover that they're currently on SH2, and force a login.
You probably could do this by manipulating cookies and session keys, but I suspect an easier way would be to use an Authentication backend. What you'll be writing is an authentication backend that is very similar to Django's own backend - except that it will be making checks of cross-domain login status against the central source of truth.
How you implement that "source of truth" is up to you - an in memory cache, database table, or any other source of data will do. The key idea is that you're not trying to rewrite cookies so that the same cookie works on every site - you're keeping each site's cookies independent, but using Django's authentication infrastructure to keep the cookies synchronised as a user moves between domains.
I have a page where user is asked only for the payment amount, then user will be redirected to another website where the payment will be processed, I want the amount to be set on the redirected page without using querystring,cokkie, etc..
I tried to use web service but here is my challange:
user enters amount on the website.
webservice is called and set the amount to ex:400$
then user is redirected without any query string to another website.
Now:
how this payment website will know that this user is the user entered 400$ on the redirecting page?
I can count on approaches more secure than this also.
thanks
I have made some research on net and asked my experienced friends, the answer is "impossible" this way.
Because redirected website somehow identify that user and there is no solution without querystrings or browser related components,
Here is my friend's advice and i am little bit satisfied, not totally :)
He calls this approach as ticketing,
First create a datetime.now integer, with that number add id and amount of money to be processed.
Then make a complex function to encrypt data. take square of every odd digit then divide to 7 etc.
then on the other website, decrypt data and check datetime if its within 5 minutes for example,
the link is valid.
You have to pass the data to the other website somehow.
Cookies wouldn't work due to domain restrictions.
Query string or form posts could work, but you don't want to use query strings.
Alternatively, if both sites share infrastructure, you could use that to share information - for example if they both have access to the same database, you could use that to share data (though you would still need to identify the specific user to both sites).
The way the service would have to work is to give back some token, probably a GUID, that the site will then look for in the querystring of an HTTP request, to identify the owner of that pre-populated data. You then tack that token onto your redirect, and the client makes a request that causes the payment site to go pull the pre-loaded data for that client.
You still have to use a query string, but now, the query string doesn't contain any human-consumable information; they can't identify their $400 amount in the query string and change it to a different amount of money. If they change the GUID at all, the request will most likely fail as that GUID won't exist in whatever datastore of pre-populated data exists behind the payment site.
Contact the website/web service/gateway. They will provide you the API which will define parameters and methods to accept payment amount. If you are the author of such service, provide mechanism to accept such parameters from your caller application. Communication should be secure, using SSL.
For example for payment gateway Paypal, check this for ideas:
Use of the PayPal payment system in ASP.NET
Have a look on wikipedia.
Shortly the answer is impossible this way, because somehow the redirect website should identify the user, all the ways are browser related or ip ( which can cause many issues later)
I've a forum where anonymous is allowed to post, protected by CAPTCHA. For users convenience, I set a Cookie for such a user which lasts about a month so the user does not get the CAPTCHA over and over again. In the simplest form the cookie is called no_captcha_for_one_month and it's value is 1. When the user returns and posts anonymously, he gets not CAPTCHA.
Anyone seeing the flaw? A forum spammer just needs to fill out the CAPTCHA correctly once and use the cookie information for his bot and there he goes.
I thought about getting creative and using a server-side hash which includes e.g. users IP address and some secret salt to generate the cookie value, but it would still be valid for this IP address, of course.
Someone I get the impression the question is silly and I try to solve something unsolvable.
I would recommend implementing your cookie value + salt implementation not to solve your problem but for security reasons. As explained by this blog post wordpress had a similar, albeit it much more severe, problem due to poor cookie security. In your case a determined spammer could always bypass your CAPTCHA even if the cookie had expired.
In order to solve the proposed problem the only solution that is coming to my mind would be to implement a Forced CAPTCHA algorithm that would override your newly secured cookie if it felt the user was being spammy. Off the top of my head I would use attributes like time since last post, number of posts today, the length of time it took to compose the message on the form, etc.
Edit: I should also mention that you can make your forum less attractive to spammers in the first place by implementing the rel="nofollow" attribute on user submitted links. See Wikipedia.
with such a solution it is always possible to use the cookie for a bot. no matter what you try.
As said below, a cookie can easily be taken from a browser and pasted in a bot code, so the solution isn't robust.
Other solutions:
Find some users posting a lot in the forum and ask them if they are volunteer to be moderator. A forum like the AutoHotkey one uses this system, and this works fine. Spammers tend to avoid active forums where moderation is fast and efficient. They prefer dead forums...
Limit the number of anonymous posts per IP address. Can be annoying for users, but can avoid spam flooding. Should be set up only if you experience such flooding.
Even worse, because you are using a cookie, the spammer doesn't even need to do the CAPTCHA once. Cookies can be changed by the client, they are sent by the browser with the page request, so the client can send whatever it wants. In fact spam requests would come from a script, so it's even easier to fabricate the cookies.
Storing the variable server side sill solve the problem I've mentioned; You set a random hash as the cookie, and have a table that stores the CAPTCHA status on the server. For the spammer to get no CAPTCHA, they would have to guess a hash that has the correct variable stored server side, shich is very hard to do.
The problem you mentioned; the fact that once a month might not be long enough to deter a spammer, you can't get around that. You have to show a CAPTCHA to every real user, as often as you want the spammer to enter one as well. Remember, a CAPTCHA is necessary because you can't tell a spammer from a normal user.
You should have the CAPTCHA show often, it will convince people to sign up anyway.
Encrypt the time (in pico or nano seconds) set it as a input value () & set it in your DataBase with a column name 'hash'
set that in every page & see if it matches the DB.
Intro
I am working on an e-commerce website. And we want to add a feature where a user can refer others via a custom link e.g.:
http://example.com/a1t2312 or http://example.com/?ref=a1t2312 (a1t231 being the referral code).
A user following such a link, will navigate a few pages on the site. And if he reached the 'buy' page and purchases something - the original referrer will get a discount.
The question is:
What is the best method to track the referral code? Put it in the user's cookies? Stick it somehow into the session? Other method?
I would definitely use cookies, as it is the easiest (but not foolproof, though). Sessions are by site, so that won't work, unless the receiving site has some code to handle the user.
All methods mentioned by you are OK. If I were you I would consider using sessions because it is more natural to me.
disclaimer: session has some limitations when you want to build application ready for heavy-load. For complicated demployment scenarios avoiding sessions might be a good choice.
I have a internal website that users log into. This data is saved as a cookie. From there the users go on their merry way. Every so often the application(s) will query the authentication record to determine what permissions the user has.
My question is this: Is it more efficent to just query the cookie for the user data when it is needed or to save the user information in viewstate?
[Edit] As mentioned below, Session is also an option.
Viewstate is specific to the page they are viewing, so its gone once they go along thier merry way. Not a good way to persist data.
Your best bet is to use Forms Authentication, its built in to ASP.NET and you can also shove any user-specific information into the Forms Authentication Ticket's Value. You can get 4000 bytes in (after encrypting) there that should hold whatever you need. It will also take care of allowing and denying users access to pages on the site, and you can set it to expire whenever you need.
Storing in the session is a no-no because it scales VERY poorly (eats up resources on the server), and it can be annoying to users with multiple browser connections to the same server. It is sometimes unavoidable, but you should take great pains to avoid it if you can.
Personally, I prefer using a session to store things, although the other developers here seem to think that's a no-no.
There is one caveat: You may want to store the user's IP in the session and compare it to the user's current IP to help avoid session hijacking. Possibly someone else here has a better idea on how to prevent session hijacking.
You can use session data - that way you know that once you have stored it there, users can't fool around with it by changing the query string.
I would use the cookie method. Session is okay but gets disposed by asp.net on recompile, and you have to use a non session cookie if you want to persist it after session anyway. Also if you ever use a stateserver its essentially doing the same thing (stores session in the db). Session is like a quick and dirty fix, real men use cookies.