Other tabs that can be enabled in the tools settings are:
DOM
Shader Editor Canvas Web Audio Scratchpad
Open Developer Tools and go to Storage | Cookies:
2.
We can change any of the cookie's values by double-clicking on them and entering a new one.
Now, we can also use a plugin to check and edit cookies. On Firefox's top bar, 3. click on the Cookies Manager button:
In the preceding image, we can see all the cookies stored at that time, and the sites they belong to, with this add-on. We can also modify their values, delete them, and add new ones.
Select PHPSESSID from 192.168.56.11 and click on Edit.
4.
Change the Http Only value to Yes:
5.
The parameter we just changed (Http Only) tells the browser that this cookie is not allowed to be accessed by a client-side script.
How it works...
Cookies Manager is a browser add-on that allows us to view, modify, or delete existing cookies and to add new ones. As some applications rely on values stored in these cookies, an attacker can use them to inject malicious patterns that might alter the behavior of the page or to provide fake information in order to gain a higher level of privilege.
Also, in modern web applications, session cookies are commonly used and often are the only source of user identification once the login is done. This leads to the possibility of impersonating a valid user by replacing the cookie's value for the user of an already active session.
There's more...
When implementing penetration testing on web applications, we should pay attention to certain characteristics in the cookies to verify that they are secure:
Http Only: If a cookie has this flag set, then it will not be accessible through scripting code; this means that the cookie values can only be altered from the server. We can still use the browser tools or a plugin to change them, but not a script within the page.
Secure: The cookie won't be transferred through unencrypted channels; if a site uses HTTPS and this flag is set in the cookie, the browser won't take or send the cookie when the requests are done through HTTP.
Expires: If the expiration date is set to the future, it means that the cookie is stored in a local file and will be kept even after the browser closes. An attacker could get this cookie directly from the file and perhaps steal a valid user's session.
Taking advantage of robots.txt
One step further into reconnaissance, we need to figure out if there is any page or directory in the site that is not linked to what is shown to the common user, for example, a login page to the intranet or to the Content Management Systems (CMS) administration. Finding a site similar to this will expand our testing surface considerably and give us some important clues about the application and its infrastructure.
In this recipe, we will use the robots.txt file to discover some files and directories that may not be linked to anywhere in the main application.
How to do it...
To illustrate how a penetration tester can take advantage of robots.txt, we will use vicnum, a vulnerable web application in vm_1, which contains three number and word guessing games. We will use information obtained through robots.txt to increase our chances of winning those games:
Browse to http://192.168.56.11/vicnum/.
1.
Now, we add robots.txt to the URL and we will see the following:
2.
This file tells search engines that the indexing of the directories jotto and cgi- bin is not allowed for every browser (User-agent). However, this doesn't mean that we cannot browse them.
Let's browse to http://192.168.56.11/vicnum/cgi-bin/: 3.
We can click and navigate directly to any of the Perl scripts (.pl files) in this directory.
Let's browse to http://192.168.56.11/vicnum/jotto/. 4.
Click on the file named jotto. You will see something similar to the 5. following screenshot:
jotto is a game about guessing five-character words; could this be the list of possible answers? Play the game using words in that list as answers. We have already hacked the game:
How it works...
robots.txt is a file used by web servers to tell search engines about the directories or files that they should index and what they are not allowed to look into. Taking the perspective of an attacker, this tells us whether there is a directory in the server that is accessible but hidden to the public using what is called security through obscurity (that is, assuming that users won't discover the existence of something if they are not told about it).
Using Proxies, Crawlers, and 3
Spiders
In this chapter, we will cover:
Finding files and folders with Dirb Finding files and folders with ZAP
Using Burp Suite to view and alter requests
Using Burp Suite's intruder to find files and folders Using the ZAP proxy to view and alter requests Using ZAP spider
Using Burp Suite to spider a website
Repeating requests with Burp Suite's repeater Using WebScarab
Identifying relevant files and directories from crawling results
Introduction
A penetration test may be performed using different approaches called black, grey, and white box. Black box is when the testing team doesn't have any previous information about the application to test except the URL of the server; white box is when the team has all information about the target, its infrastructure, software versions, test users, development information, and so on; and gray box is a point in between.
For both black and gray box approaches, a reconnaissance phase, as we saw in the previous chapter, is necessary for the testing team to discover the information that could be provided by the application's owner in a white box approach.
Continuing with the reconnaissance phase in a web penetration test, we will need to browse every link included in a web page and have a record of every file displayed by it.
There are tools that help us to automate and accelerate this task; they are called web crawlers or web spiders. These tools browse a web page following all links and references to external files, sometimes filling in forms and sending them to servers, saving all requests and responses made and giving us the opportunity to analyze them offline.
In this chapter, we will cover the use of some proxies, spiders, and crawlers included in Kali Linux and will also see what files and directories would be interesting to look for in a common web page.