From the course: Complete Guide to Penetration Testing

A refresher on web technology

From the course: Complete Guide to Penetration Testing

Start my 1-month free trial Buy for my team

A refresher on web technology

“

- [Instructor] Websites are the main conduit for computer-based information, and browsers are now the preferred interface used to access application systems. There are many forms of websites, and to be a web application tester, we need to have a good working knowledge, not only of the underlying protocols used for web access, but also the structure of websites. I introduced the basics of website testing in my ethical hacking course on hacking web servers and web applications. Let's just refresh ourselves on what we learned about how websites are presented. A web application is built using HTML and script code running on a web server that offers an HTTP or HTTPS protocol access, the more recent WS and WSS web socket protocols, or the experimental quick protocol. It will likely use a backend database server or some form of flat file for content. A user will connect to the application from a browser, which may be running on a desktop, a laptop, or a mobile device. The web application may want to authenticate the user, and to do that, use some form of backend authentication system such as LDAP. It's good practice to not expose a web application server directly to the internet, and so a web proxy will be placed between the user and the web application. The proxy server takes user requests and sends them to the web application, and takes web application responses and returns them to the user. A web proxy is designed to be secure and is a much safer internet facing system than a full web server. Early web applications tended to be mainly written on the server side with forms being used to request data. Nowadays, much of the code is client side, often supported with client-side data stores. While content management systems have a standardized web folder structure, the folder structures for custom built web applications will be application specific. Also, individual web servers have their own default folder structure. This may be changed for production, but understanding what a default website would look like for each type of server is a good start. A website exists as folders on a host with the homepage of the website on a typical Linux Apache installation being located at /var/www/html, and on a typical Windows installation of IIS being in \inetpub\wwwroot. The hyper text markup language, HTML, is the basic building block of a website. A simple webpage might just start with an html tag as shown here. More usually a webpage starts with a declaration that the page is indeed HTML, written as DOCTYPE HTML. After that, the basic component of a webpage is a set of elements in between the start and end markers shown as a name bracketed with less than and greater than symbols. The start marker may additionally have attributes in between the open and close brackets. The element start is sometimes known as a tag, and there are a number of standard ones such as title, the h tag for headers, body, and the p tag for paragraph. Another useful tag is the href tag, which enables a webpage to reference another page through a hyperlink. Web designers have gone much further with the way in which webpages are crafted in order to ensure a consistent application of styles. We can use the style element for a page or for the whole website. This can be included in the page or more usually in its own file external to the HTML file. The full external styling approach is known as cascading style sheets. We'll also see tables and forms appearing in many web pages, particularly those that we're interested in as a tester. We need to understand how the forms pass data to be validated and processed as this can be an area of weakness in some sites. Forms have their own form tag, and are constructed with various elements to enable data input, and often have the div elements which define areas of the page. There are also xml, php, and javascript tags, which allow active code to be included in web pages. Here's an example of a call to an external JavaScript file and an embedded line of JavaScript code. One of the important elements of messages exchanged from a PHP driven website is the PHPSESSIONID, and this is something we'll use during our testing to enable us to work inside PHP sessions. We'll be seeing more of active code as we progressed through the course. Finally, in addition to understanding what the target looks like and how it's built from a static perspective, the web application tester also needs to be knowledgeable in the message protocols used by the application when it's operating, and particularly the two common protocols, HTTP and HTTPS. HTTP is a stateless client server protocol, which can be used from a browser or programmatically between hosts. An http://url will establish a TCP connection on port 80, as we can see here. An https:// will establish a connection by default on port 43. HTTPS will be used to set up a protected data transfer using TLS packets. It's not unusual to see a web server set up on a different port such as 8080. An HTTP exchange consists of an HTTP request message, which is sent to the web server, and an HTTP response message, which is returned. In an interactive session, the HTTP response will provide data for the user, which needs to be displayed, ie. an HTML webpage. We can see the selected response packets, in the bottom panel, is a zipped text HTML page. GET is one of eight standard request commands or methods defined in HTTP. The GET command allows a user to download a web resource from the server. This will often be a webpage specified by a file name. Omitting the file name will cause the default first page to be returned. The HEAD request is used in the same way as GET, but will download just the header or metadata. This is commonly done to check the last modified date of the page and check against a local cached copy. The POST command allows a user to upload items to the server. This is commonly used to send form data back to the server, and is the key message that's of interest to pentesters. The TRACE command requests a diagnostic trace of the actions taken by the server. The OPTIONS command ask the server to return the list of request methods it supports. The connect command causes the proxy to connect to another host. This is often used to make an SSL connection through the proxy. Two important commands, when doing web application testing, are the PUT command to send data to the server to be stored and the DELETE command to delete data. These are often not used in production systems for security reasons, but if they do exist, then we can likely take advantage of them. There are seven common status codes. 200 indicates that the request was processed without any problems. 301 means redirection for pages that have been moved. 400 is a bad request. 401 is unauthorized. 403 means access is forbidden, and the commonly seen 404 means that it's an unknown page. 500 is an internal server error. While websites often used just a few header fields, there are many that have been defined in the HTTP standard. The webpage shown here is an excellent quick reference for all the HTTP header fields that you might come across during testing.

Contents