8. Cross Site Request Forgery
Now, the next topic I want to talk about is something that is really a subset of crosssite scripting or a form of crosssite scripting. It’s called crosssite request forgery. And what it does is it leverages trust you have with some site into fooling you to doing on something else. This is one of the biggest reasons that banks will log us off for a period of inactivity. Because if the browser tab is available, then it’s quite possible, since we’re already authenticated, to do something like this to us. All right, let me see if I can explain it a little bit better. Consider anyone who can load content into your user’s browser and thus force them to submit a request to your website, including any website or other HTML feed that your users visit.
Exploitability capability would be something along the lines where attackers create a forged Http request and trick a victim into submitting them via HTML tags. Iframes cross site scripting or other malicious techniques if the user is authenticated already, then the attack would succeed. What’s the prevalence? It’s actually fairly uncommon, but it’s pretty easy to death. Now, cross site request forgery takes advantage of the fact that most web apps allow attackers to predict all the details of a particular action. Because browsers send credentials just like session cookies, automatically, attackers can create malicious pages which generate forged requests that are indistinguishable from legitimate ones.
The detection of cross site request forgery flaws is fairly easy via penetration test or code analysis. Now, what you need to do is consider the business value of affected data or application functioning. Imagine not being sure if users intended to take these actions. So transfer money as an example. Consider the impact to your reputation. I used as an example the bank account and the reason that banks will typically log you off after a period of inactivity, which is probably a very good idea. Take a look at this example here. The very first thing, we click on a hyperlink. The second thing that happens is a hidden request is passed to an unintended request destination.
It then issues back a response with the token that is then sent back to us. We, since it had this on it, we request something else with the tokens and don’t really even know all this is actually happening. One form of cross site request forgery is clickjacking. Now, clickjacking is possible because seemingly harmless features of HTML web pages can be employed to perform unexpected actions. Also, most sites do not enforce something called the same origin policy. This is where the same site that you made a request from is the same site. The response back from a clickjack page tricks a user into performing undesired actions by clicking on a concealed link.
Typically what it is is a transparent. Iframe an area that’s laid over something you would typically click on, the URL of the transparent area leads you to a malicious site that you didn’t really want to click on. So if we laid over an iframe that was completely clear, and we clicked on the OK button or some other button that’s on our bank site, it would leverage what we thought we wanted to do to doing something perhaps malicious. The users think that they’re clicking on visible buttons while they’re actually performing actions on a hidden page. The hidden page may be an authentic page, therefore the attackers can trick users into performing actions which users really never even intended.
There’s no way of tracing such actions to the attackers later, as the user would have been genuinely authenticated on that hidden page, because that’s exactly what you did. Now, an iframe itself can have a visibility of completely transparent, or it can be completely opaque where you would not be able to see through it. Now naturally they’re going to set it up to where it’s completely transparent. If you hover over the button you’re fixing to click on down in the tray that is located somewhere here, it will show you what you’re actually fixing to click on. And if we could get everyone to be able to look at that before they clicked on it, well then Cross Site Request Forgery would be a thing of the past.
Unfortunately, I don’t think that’s going to be a possibility. Let’s talk about prevention. So how do I prevent cross site request forgery? Now, the preferred option is to use an existing Cross Site Request Forgery defense. Many frameworks include this in the cross site request forgery defenses such as Spring play, python Django AngularJs. Some web development languages like Net do so as well. Osp has one called Cross Site Request Forgery Guard, which can actually automatically add Cross Site Request Forgery defenses. In Java applications, they also have a Cross Site Request Forgery protector does the same thing for PHP or acts as an Apache filter.
Otherwise, preventing Cross Site Request Forgery usually requires an inclusion of an unpredictable token in each Http request. Now, such tokens should at minimum be a unique Per user per session. The preferred option is to include the unique token in a hidden field. This includes the value of the body of the Http request, avoiding its exposure in the URL. The unique token can also be included in the URL or parameter. However, this runs the risk the token is going to be exposed. Consider using same site equals strict flag on all cookies, which is increasingly supported in browsers.
9. Cookies and Session Management
Now let’s go ahead and talk about cookies. We all know that Http is stateless. Now, what does that mean? That means we are actually transferring a file from point A to point B. Then we’re done without URL parameter passing or some type of session IDs. In other words, a cookie. The web server has no idea who you are from one packet to the next. Some forms of session IDs might be an ASP or an active server page session ID, a PHP session ID, a jsp session ID, a CFID or CF token as an example. Now, the way I like to explain cookies is I like to bring up the movie A 51st Date.
You may remember it with Drew Barrymore and Adam Sandler, where Drew Barrymore wakes up each day and doesn’t know anything from the previous days. So this is kind of the way that a website appears to a browser if we didn’t use a cookie. So if we go to the website it may say, well, who are you? Let me type in my user ID and password. The next item we click on, it says who are you? I just told you that my name is Jim. And so on the next thing we click on who are you? It gets to be pretty monotonous, doesn’t it? So that’s what the cookie does for us. The cookie performs this form of session management for us it is always passed every time we click on something.
So a cookie is always passed every time we move from one HTML link to another. We talked already about ways of intersecting the cookie. If we are able to intercept that cookie, we could grab it and it would think that, oh, we are that person, when in fact it really is an attacker. Now, cookie is also known as an Http cookie, a web cookie, a browser cookie, a session data cookie. All this is a small piece of data sent from a website and stored in a user’s web browser while the user is browsing that particular website. Every time the user loads the website, the browser sends the cookie back to the server to notify the website of the user’s previous activity.
Cookies were designed to be a reliable mechanism for websites to remember stateful information such as, let’s say, items that are in your shopping cart or to record the user’s browsing activity, including clicking particular buttons, logging in session details, or recording pages where you visited by the user as far back as months or even years ago. Although cookies themselves cannot carry viruses, it cannot install malware on the host computer. Something called tracking cookies, and especially third party tracking cookies are commonly used as ways to compile long term records of individuals browsing history, a potential privacy concern that prompted European and US.
Lawmakers to take action in 2011. Cookies can also store passwords and form content a user has previously entered, such as credit card number or an address. When a user accesses a website with a cookie function for the first time, a cookie is sent from the server to the browser and stored with the browser in the local computer. Later that user goes back to the same website. That website will recognize that user because of the stored cookie with the user’s information. I previously used as an example that you sent an email using a web based email program. You clicked the x button to close out the browser and thought oh, I need to go back in there and send another email.
When you went back in and went to that website, it logged you back in. You are already logged in. Well, that’s a cookie that’s doing that. Other kinds of cookies perform essential functions in the modern web. Perhaps most importantly, authentication cookies or off cookies are the most common method used by web developers and web servers to know whether the user is logged in or not and which account they are logged in with. Without such a mechanism, the site would not know whether to send a page containing sensitive information or require the user to authenticate themselves by logging in. The security authentication cookie generally depends on the security issuing the website and the user’s browser.
In other words, are we using SSL or not? And whether the cookie data is encrypted. So security vulnerabilities may allow cookies data to be read by a hacker used to gain access to that data or to gain access with the user’s credentials to the website to which the cookie belonged. Now, I should clarify when I said with the user’s credentials, in reality they’re not able to grab the credentials unless that’s stored in the cookie, which would be a little bit silly. Usually it’s a session that’s stored in the cookie. This is the reason when things that are required to be performed on a website that takes significant action, like changing your password, for example, it makes you log back in authenticate again. This way if somebody did steal your session, they cannot change your password and lock you out.
10. OWASP Top 10
There’s an organization called the Open Web Application Security Project and they create a top ten vulnerabilities every several years. The last one just came out in 2013 and this one just came out in 2017. It was just like less than a month ago. And they rate the most significant attacks all the way down to the these significant attacks, the top ten, if you will. Now, who’s been at the top of the list for the last, I think ten years I can remember, has been injection injection flaws like SQL injection, operating system injection, in other words, command injection, XE injection, and LDAP injection. And they typically occur when untrusted data is sent to an interpreter and we don’t know what’s a command and what is actually the query.
So the attacker injects hostile information in here tricking the interpreter to executing unintended commands or accessing data without that proper authorization. The next one on the list is broken. Authentication or session management and applications that functions that are related to authentication, they often are implemented correctly. The programmer didn’t do a good job, in other words. This allows attackers to be able to compromise things like passwords and keys, session tokens, for example, in order to exploit other implementation flaws in order to take on users identity either temporarily or permanently.
We talked about cookies being a form of session management and if we intercepted someone’s cookies, then they would take on that person’s identity and that person’s identity would be taken on for as long as that cookie is valid. And cookies are typically valid depending upon the lifetime of that cookie. Cookies are valid, for example, in their bank account from login to login. But cookies, maybe in your web browser that you’re using to get access to your email, if used by the default, they could last up to a year. We also talked about cross site scripting. And remember, cross site scripting is just simply where we inject untrusted data onto some type of web page without the proper validation or we escape the characters properly and it executes whenever the web page is refreshed.
Keep in mind we talked about this where the website simply reads from the top and goes to the bottom. It doesn’t know what was injected by a cross site scripting attack. Then we have broken access control. This is what happens when authenticated users are allowed to do things without being properly enforced. We talked a little bit about this when we discussed things like logic flaws, where we got into Joe’s email and then went over to Sue’s email. As an example, security misconfiguration happens whenever a secure configuration defined by the employee or deployed for the application framework or application server, even the web server database, whatever the platform might happen to be, those secure settings should be defined, implemented and maintained as defaults.
And sometimes those defaults are often insecure. Additionally, software should be kept up to date. Sometimes the framework itself will have a flaw and that framework allows people in. There was a huge one just a couple of years ago on Drupal, and it was very much attacked. Next one we have is the next one we’ve got is Sensitive data Exposure. Now, a lot of the web applications and of course the application programming interfaces, they don’t often protect that sensitive data in the way that they should. Like, for example, financial information, health care, Pii, which is personally identifiable information. Attackers could steal it and modify it if it’s not protected well, to conduct credit card fraud, maybe identity theft, or even other crimes.
Now, the census date deserves this extra protection, such as encryption at Rest. In other words, if you have a credit card stored on your machine and to be compatible with the credit card companies, that must be encrypted. A lot of people don’t actually follow those rules. Another one would be encryption in transit. And we typically use SSL for this, as well as special precautions exchanged within the browser. And I didn’t really talk about that, which are things like Http only cookies and other things. And that’s really more for the week long course that I do where I go into a lot of that. The next one we want to talk about is insufficient attack protection. Now, applications themselves generally have the lack of basic ability to detect, prevent, and then even respond to both manual and automated attack.
What happens is the attack protection goes far beyond basic input validation, and it could do things like automatically detect, log and respond or even block attacking exploits. Application owners also need to be able to deploy patches quickly in order to protect against attacks that are realized after something is put out. We had a little discussion on Cross site Request Forgery and the cross site Request Forgery, if you recall, leverages the trust we have with one site to to inadvertently do something on another. Number nine was using components with known vulnerabilities. These are libraries that are known to be bad frameworks, that are known to be outdated or other software modules or run with the same privileges as the application. We talked about this with the web server.
We always run the web server as something other than root or administrator because if it is compromised, they won’t be able to do as much on their applications. And APIs using components with known vulnerabilities may undermine the whole application defense and enable various attacks. This one is actually a little bit new for 2017. The modern applications involve rich content and applications, and something called APIs APIs is going to be very, very popular, such as JavaScript in the browser, mobile apps that connect to an API of some kind, like a Soap, XML, Rest, or Json type of a query, RPC, Gwt, something like that. These APIs are often unprotected to contain numerous vulnerabilities themselves. In reality, the API is always going to find itself out to the web.
