PHP Parse error: syntax error, unexpected $end in on line – The Error and The Fix

While working on a test web application, last night, I hit upon the following error, which for a second had me lost.

I checked to see if I had the opening and the closing tags correct. Upon further investigation, I found that this was due to my using the “short tag” for PHP in the html_functions.php file. I normally use “” to close my PHP statements, but in this particular file, I had missed on the “php” and had accidentally used “<?" to open a statement.

As it is evident from the image, I use XAMPP to host test applications, when developing on Windows. To find more about this setting I did some reading on a specific setting in php.ini called “short_open_tag”. I opened the php.ini inside “c:\xampp\php\php.ini” – which is the default location for XAMPP, and searched for the “short_open_tag” setting. This specific setting was set to “off”, so the quickfix was to merely change the setting to “on”, restarting Apache and reloading the page. The setting in the php.ini finally looked like this:

short_open_tag = On

The following paragraph explains the setting better, taken from the php.ini file.

This directive determines whether or not PHP will recognize code between tags as PHP source which should be processed as such. It’s been recommended for several years that you not use the short tag “short cut” and instead to use the full tag combination. With the wide spread use of XML and use of these tags by other languages, the server can become easily confused and end up parsing the wrong code in the wrong context. But because this short cut has been a feature for such a long time, it’s currently still supported for backwards compatibility, but we recommend you don’t use them.

Default Value: On
Development Value: Off
Production Value: Off

Problem solved, I spent the rest of the time I had on some fancy GUI and cookie monsters 😀

Multiple Vulnerabilities with the Cisco Developer Network

I found a bunch of vulnerabilities with Cisco subdomains a couple of weeks ago, some of them were plain old XSS vulnerabilities,while others were more interesting. Cisco is yet to fix some of them which I will not be talking about here, however I will discuss the other issues that I found and which have now been fixed.

I found an XSS on the domain, and since Cisco uses Single Sign On for most of its subdomains, an attacker could simply exploit this issue and gain access to the user accounts under other Cisco domains. The Cisco Developer Network runs on a well known product, which is actively maintained by the developers and used worldwide by several major corporations. 

For the noobs, An XSS or Cross Site Scripting vulnerability occurs when an application accepts user input and sends it back to the browser without removing/encoding malicious characters. Malicious characters are any set of characters that a browser can use to render HTML or script content (,”,/> etc..). So, instead of displaying the user input, the browser will render/execute it depending on whether the input was HTML tagged content or script content.

XSS can cause a lot of serious problems. An attacker can steal cookies, redirect users to fake or malicious sites, control a user’s browser using automated frameworks like BeEF and download and execute exploits on the victim’s computer.

The other issue I found was particularly interesting because the application failed to check necessary user privilege levels while a user attempted access to application modules that were obviously sensitive. To this effect, I was able to locate the administration modules of several key sections under that would have allowed me to upload files, change and delete the content that users would see. I had access to all available administrative tasks since the application was clearly not checking whether I had admin or guest privileges. To make things worse, Google had traversed and cached these pages which would allow an attacker to reach to all the administration modules following an advanced Google search.

Now that both the issues have been fixed, here’s a finer look at the vulnerabilities:

1. XSS in the Cisco Developer Network (
The following pages accept client side input via the ‘_153_keywords’ parameter and render it back to the browser without sanitization.

This was a POST based XSS, hence to craft an attack vector, an attacker would need to create a page that autosubmits a form on page/body. 

2. Insufficient privilege/permission check on the Cisco Developer Network.
The application did not verify the permission levels of logged in users when providing access to the administration modules of several sections listed on under “Available Technology Centers”

Some examples were: 


An advanced Google search, like the following, can get a list of modules that were  vulnerable:|%20inurl:administration

Waiting for Cisco to fix some other issues on several other domains before I disclose them here. Till then Happy Hacking!