CMS Showcase 1.0 Cross Site Scripting

Title:
=======
CMS Showcase - Multiple Reflected Cross-Site Scripting

Introduction:
============&# Title:
=======
CMS Showcase - Multiple Reflected Cross-Site Scripting

Introduction:
==============
A content management system (CMS)] is a computer application that supports the creation and modification of digital content.
It is often used to support multiple users working in a collaborative environment.
CMS features vary widely. Most CMSs include Web-based publishing, format management, history editing and version control, indexing, search, and retrieval.
By their nature, content management systems support the separation of content and presentation.

Vulnerability Disclosure:
==========================
2017-07-07: Public Disclosure

Affected Product(s):
=====================
CMS Showcase 1.0

Exploitation Technique:
========================
Remote

Severity Level:
================
High

Technical Details & Description:
=================================
A Reflected Cross-Site Scripting web vulnerability has been discovered in the CMS Showcase web-application.
The vulnerability is located in the `language` & 'id_categoria' parameter of the`main.php` action GET method request.

Request Method(s):

[+] GET

Vulnerable Function(s):

[+] main.php

Vulnerable Parameter(s):

[+] language

[+] id_categoria

Proof of Concept (PoC):
========================
Cross-site Scripting (XSS) is an attack technique that involves echoing attacker-supplied code into a user's browser instance.
A browser instance can be a standard web browser client, or a browser object embedded in a software product such as the browser within WinAmp, an RSS reader, or an email client.
The code itself is usually written in HTML/JavaScript, but may also extend to VBScript, ActiveX, Java, Flash, or any other browser-supported technology.
When an attacker gets a user's browser to execute his/her code, the code will run within the security context (or zone) of the hosting web site.
With this level of privilege, the code has the ability to read, modify and transmit any sensitive data accessible by the browser.
A Cross-site Scripted user could have his/her account hijacked (cookie theft), their browser redirected to another location, or possibly shown fraudulent content delivered by the web site they are visiting.
Cross-site Scripting attacks essentially compromise the trust relationship between a user and the web site.
Applications utilizing browser object instances which load content from the file system may execute code under the local machine zone allowing for system compromise.


[+] http://www.ugualiepartecipi.it/pages/struttura/main.php?id_categoria="><marquee>XSS/marquee>&id_singola=133&page=1

[+] http://www.ugualiepartecipi.it/pages/struttura//main.php?id_categoria=1&language="><marquee>XSS</marquee>

Solution
=========
Phase: Architecture and Design
Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.

Phases: Implementation; Architecture and Design
Understand the context in which your data will be used and the encoding that will be expected.
This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages.
Study all expected communication protocols and data representations to determine the required encoding strategies.
For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters.
Consult the XSS Prevention Cheat Sheet for more details on the types of encoding and escaping that are needed.

Phase: Architecture and Design
For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602.
Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely.
Then, these modified values would be submitted to the server.
If available, use structured mechanisms that automatically enforce the separation between data and code.
These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated.

Phase: Implementation
For every web page that is generated, use and specify a character encoding such as ISO-8859-1 or UTF-8.
When an encoding is not specified, the web browser may choose a different encoding by guessing which encoding is actually being used by the web page.
This can cause the web browser to treat certain sequences as special, opening up the client to subtle XSS attacks. See CWE-116 for more mitigations related to encoding/escaping.
To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly.
In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie.

This is not a complete solution, since HttpOnly is not supported by all browsers. More importantly, XMLHTTPRequest and other powerful browser technologies provide read access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set.
Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a whitelist of acceptable inputs that strictly conform to specifications.
Reject any input that does not strictly conform to specifications, or transform it into something that does. Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a blacklist).
However, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules.
As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if you are expecting colors such as "red" or "blue."
Ensure that you perform input validation at well-defined interfaces within the application. This will help protect the application even if a component is reused or moved elsewhere.

Credits
========
Felipe "Renzi" Gabriel

Contact
========
renzi@linuxmail.org

References
==========
http://projects.webappsec.org/Cross-Site-Scripting
http://cwe.mitre.org/data/definitions/79.html
https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)
https://en.wikipedia.org/wiki/Content_management_system
https://cxsecurity.com/issue/WLB-2017070095