what you don't know can hurt you

CMS Showcase 1.0 Cross Site Scripting

CMS Showcase 1.0 Cross Site Scripting
Posted Sep 8, 2017
Authored by Renzi

CMS Showcase version 1.0 suffers from multiple cross site scripting vulnerabilities.

tags | exploit, vulnerability, xss
MD5 | 5d11519fb46a0665b18c2da1518aa1ee

CMS Showcase 1.0 Cross Site Scripting

Change Mirror Download
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

Comments

RSS Feed Subscribe to this comment feed

No comments yet, be the first!

Login or Register to post a comment

File Archive:

September 2017

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Sep 1st
    5 Files
  • 2
    Sep 2nd
    5 Files
  • 3
    Sep 3rd
    3 Files
  • 4
    Sep 4th
    13 Files
  • 5
    Sep 5th
    16 Files
  • 6
    Sep 6th
    15 Files
  • 7
    Sep 7th
    20 Files
  • 8
    Sep 8th
    16 Files
  • 9
    Sep 9th
    4 Files
  • 10
    Sep 10th
    2 Files
  • 11
    Sep 11th
    15 Files
  • 12
    Sep 12th
    19 Files
  • 13
    Sep 13th
    20 Files
  • 14
    Sep 14th
    38 Files
  • 15
    Sep 15th
    31 Files
  • 16
    Sep 16th
    1 Files
  • 17
    Sep 17th
    7 Files
  • 18
    Sep 18th
    15 Files
  • 19
    Sep 19th
    40 Files
  • 20
    Sep 20th
    8 Files
  • 21
    Sep 21st
    1 Files
  • 22
    Sep 22nd
    0 Files
  • 23
    Sep 23rd
    0 Files
  • 24
    Sep 24th
    0 Files
  • 25
    Sep 25th
    0 Files
  • 26
    Sep 26th
    0 Files
  • 27
    Sep 27th
    0 Files
  • 28
    Sep 28th
    0 Files
  • 29
    Sep 29th
    0 Files
  • 30
    Sep 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2016 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close