Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Community
Ask the community for help and clear up your study doubts
Discover the best universities in your country according to Docsity users
Free resources
Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors
web server hacking and web application hacking
Typology: Lecture notes
1 / 10
This page cannot be seen from the preview
Don't miss anything!
SRI KRISHNA COLLEGE OF TECHNOLOGY (An Autonomous Institution | Affiliated to Anna University Chennai | Accredited by NBA and NAAC with A Grade) COIMBATORE 641042
So far, the attack techniques we have described have all involved interacting with a live running application and have largely consisted of submitting crafted input to the application and monitoring its responses. This chapter examines an entirely different approach to finding vulnerabilities — reviewing the application’s source code. In various situations it may be possible to perform a source code audit to help attack a target web application: Some applications are open source, or use open source components, enabling you to download their code from the relevant repository and scour it for vulnerabilities. If you are performing a penetration test in a consultancy context, the application owner may grant you access to his or her source code to maximize the effectiveness of your audit. You may discover a fi le disclosure vulnerability within an application that enables you to download its source code (either partially or in its entirety). Most applications use some client-side code such as JavaScript, which is accessible without requiring any privileged access. It is often believed that to carry out a code review, you must be an experienced programmer and have detailed knowledge of the language being used. However, this need not be the case. Many higher-level languages can be read and understood by someone with limited programming experience. Also, many types of vulnerabilities manifest themselves in the same way across all the languages commonly used for web applications. The majority of code reviews can be carried out using a standard methodology. You can use a cheat sheet to help understand the relevant syntax and APIs that are specific to the language and environment you are dealing with. This chapter describes the core methodology you need to follow and provides cheat sheets for some of the languages you are likely to encounter.
to help you attack web applications. This chapter examines how these tools work and describes how you can best use their functionality. The second main category of tool is the standalone web application scanner. This product is designed to automate many of the tasks involved in attacking a web application, from initial mapping to probing for vulnerabilities. This chapter examines the inherent strengths and weaknesses of standalone web application scanners and briefly looks at some current tools in this area. Finally, numerous smaller tools are designed to perform specific tasks when testing web applications. Although you may use these tools only occasionally, they can prove extremely useful in particular situations.
A web browser is not exactly a hack tool, as it is the standard means by which web applications are designed to be accessed. Nevertheless, your choice of web browser may have an impact on your effectiveness when attacking a web application. Furthermore, various extensions are available to different types of browsers, which can help you carry out an attack. This section briefly examines three popular browsers and some of the extensions available for them. Internet Explorer Microsoft’s Internet Explorer (IE) has for many years been the most widely used web browser. It remains so by most estimates, capturing approximately 45% of the market. Virtually all web applications are designed for and tested on current versions of IE. This makes IE a good choice for an attacker, because most applications’ content and functionality are displayed correctly and can be used properly within IE. In particular, other browsers do not natively support ActiveX controls, making IE mandatory if an application employs this technology. One restriction imposed by IE is that you are restricted to working with the Microsoft Windows platform. Because of IE’s widespread adoption, when you are testing for cross-site scripting and other attacks against application users, you should always try to make your attacks work against this browser if possible
Firefox is currently the second most widely used web browser. By most estimates it makes up approximately 35% of the market. The majority of web applications work correctly on Firefox; however, it has no native support for ActiveX controls. There are many subtle variations among different browsers’ handling of HTML and JavaScript, particularly when they do not strictly comply with the standards. Often, you will find that an application’s defence against bugs such as cross-site scripting mean that your attacks are not effective against every browser platform. Firefox’s popularity is sufficient that Firefoxspecific XSS exploits are perfectly valid, so you should test these against Firefox if you encounter difficulties getting them to work against IE. Also, features specific to Firefox have historically allowed a range of attacks to work that are not possible against IE, as described
Chrome is a relatively new arrival on the browser scene, but it has rapidly gained popularity, capturing approximately 15% of the market. A number of browser extensions are available for Chrome that may be useful when attacking web applications, including the following: n XSS Rays is an extension that tests for XSS vulnerabilities and allows DOM inspection. n Cookie editor allows in-browser viewing and editing of cookies. Wappalyzer is also available for Chrome. n The Web Developer Toolbar is also available for Chrome. Chrome is likely to contain its fair share of quirky features that can be used when constructing exploits for XSS and other vulnerabilities. Because Chrome is a relative newcomer, these are likely to be a fruitful target for research in the coming years. Intercepting Proxies and HTTPS When dealing with unencrypted HTTP communications, an intercepting proxy functions in essentially the same way as a normal web proxy, as described in Chapter 3. The browser sends standard HTTP requests to the proxy, with the exception that the URL in the first line of the request contains the full hostname of the destination web server. The proxy parses this hostname, resolves it to an IP address, converts the request to its standard non proxy equivalent, and forwards it to the destination server. When that server
WEB SERVER HACKING
A web server is a program that stores files (usually web pages) and makes them accessible via the network or the internet. A web server requires both hardware and software. Attackers usually target the exploits in the software to gain authorized entry to the server. Let’s look at some of the common vulnerabilities that attackers take advantage of.
The following is a list of the common web servers
the internet. Most asp and aspx websites are hosted on IIS servers.
