Sociology (or social-engineering) is more or less the same approach a con-man would use to get what he wants. Calling McDonalds to complain they messed up your order, when you never even placed an order just to get a free meal is a perfect example of sociology. On the world wide web, an attacker might use sociology to trick you into clicking a link that you shouldn't have, or opening an e-mail attachment, or something along those lines. This section will cover a few examples of sociology, and how to protect your visitors and personal reputation from such attacks.
Sessions
When you make a request for a webpage, a connection is made, the page is generated, and then that connection ends until you make another request. For this reason, HTTP is considered "stateless", and sessions were created as a way of keeping track of a visitor's state as they jump around your website making multiple connections. There is no consistent or streaming communication with the server although it seems people are trying to change that, perhaps to make web applications more like software (another topic not suited for this article).
Sessions work by creating a unique ID for each visitor, which remains the same no matter how many requests are made until that session expires (usually after about 20 minutes or so of no activity). The session ID is used as a reference for the visitor's information. The ID can be passed from page to page in several ways, whether hidden form fields, cookies, or even passed along in the url.
Session hi-jacking occurs when an attacker is able to take over another person's active session. Depending on how the session ID is generated to begin with, he might be able to brute-force guess it. Some developers un-knowingly create very predictable ID's by using timestamps or an IP address as a basis for generating the session ID; not a good idea. The attacker might also be able to con you into giving them your ID, for example if the ID is passed along in the url and you send him a link to the site, he can now see whatever your session ID allows. You could even reverse the situation where an attacker sends you a link to a site with a pre-existing session ID; if you were to login to the site or transmit any personal information with the attacker's ID, then he would be able to see it. That is referred to as session fixation.
Probably the safest way to handle sessions would be to force your visitors to use cookies, and store the session information in a secure database. PHP has a function, session_set_save_handler() for exactly this purpose, and a great benefit is that you don't need to alter any of your existing session code to make it work. You might also consider using session_regenerate_id() to ensure that a fresh ID is created for each new login. Sessions are likely the most valuable aspect to your application, and at the same time, the most vulnerable point of attack.
Cross-Site Request Forgery Attacks
Now, Cross-site request forgery attacks (or, CSRF attacks), can certainly be performed without any type of sociology. The reason I decided to discuss them here, is because they are most easily described along with a bit of sociology. In a nutshell, a CSRF attack happens when an attacker is able to trigger an event on your behalf by taking advantage of a flaw in a system that you're currently logged into. To better understand, try to imagine a hypothetical webmail system. This webmail system contains all your standard features, the ability to change your default e-mail address (that you registered with), the ability to request a new password if you've forgotten yours, and so on... Somehow or another, the attacker got a hold of your e-mail address (which also happens to be your login username) and decides to e-mail you a link with a funny picture. You login into your webmail account and find the e-mail, it looks legit so you go ahead and click the link; you see the picture, laugh, and log out for the day. Now fast forward to the next day when you attempt to check your e-mail again, only to be informed that your password is incorrect, and for some reason the password reminder feature doesn't appear to be e-mailing you anything. What the heck is going on?
Explanation: The attacker registered an account with the same webmail system that you were using and was therefore able to familiarize himself with how everything worked. He found that the "change e-mail" feature generated some pretty predictable form elements, and not only that but the form appears to accept $_REQUEST values instead of strictly $_POST, which means it doesn't even have to be submitted in order to be processed (values could be passed in the url). The attacker wrote a simple HTML page, including the full url to change your e-mail address to his inside of an IMG tag, along with another non-broken image. When you clicked the link, you executed the script so the form was processed with your current session information. In other words, the attacker found a way to get you to change the default e-mail on your account to reflect his e-mail address without you ever even realizing it. The attacker then went back to the webmail site, and requested a new password using your login, which was e-mailed to him without any question.
You have to assume a few things about the webmail system in order for the above to actually work. Basically, the fact that it lets you change your e-mail address without any type of follow-up confirmation isn't very smart. Second, the fact that it accepts $_REQUEST values to submit the form is just plain stupid. And last, allowing the form to be processed with no verification as to whether or not the request is coming from a third party leaves room for improvement as well. In this case, the developer overlooked quite a few important security features.
Proxy Phishing
Phishing, as mentioned briefly in the XSS topic, is the idea of falsely representing a legitimate company in order to have visitors submit their personal information. That personal information is then used for the attacker's personal benefit, either in identity theft, reselling the information to a third party, or something along those lines. Most phishing attempts are pretty lame, in that they use a somewhat suspicious looking url, and they sometimes create an exact duplicate of a government/business websites template asking for personal information which government and legitimate businesses simply don't ask for. Although easy to spot for an experienced web surfer, hundreds if not thousands of people fall for it every day.
A proxy is basically a gateway for internet traffic, which allows requests for webpages and the like to be made by the gateway on your behalf, allowing users to surf the web anonymously, bypass firewalls and so on. PHProxy (http://sourceforge.net/projects/poxy/) is an open-source web based proxy application that I'm particularly fond of. Using an application like this, whatever server it is installed will act as the gateway, making requests for you, and sending the results back for you to see.
Although proxy applications can have many useful and beneficial purposes, they can also be used in a very malicious nature. For example, let's say you have a web user who stumbles upon a link to PayPal which happens to be accessing the site through a proxy application. The url looks legit, setup on a subdomain so it looks something like: http://paypal.realdomain.com/. Since they are using a proxy, they are actually interacting with the legitiment PayPal website, and they can login, register a new account, or anything they want and will receive the appropriate e-mail notifications and everything informing them that all is fine and dandy. Little does either party (PayPal or visitor) know that the information is being intercepted. The url is the only bit that gives it away for a more experienced user, but even url's have been spoofed in the past due to flaws found in certain web browsers, making it impossible to know what site you're actually visiting.
You as a developer can only do so much to protect your visitors from these types of attacks, but the most important thing is to realize what kind of attacks are out there so you can do your best to help get to the bottom of the situation. Otherwise, you might have customers blaming you for leaking their information, and you'll be left with no evidence to imply otherwise which would destroy your company's reputation.
