Please report security issues here: https://developer.joomla.org/security/contact-the-team.html

Set to "closed" on behalf of @Quy by The JTracker Application at issues.joomla.org/joomla-cms/20085

We first contacted the Joomla Security Strike Team and they said to post it
with you...

On Thu, Apr 5, 2018, 3:33 PM Quy notifications@github.com wrote:

Please report security issues here:
https://developer.joomla.org/security/contact-the-team.html

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#20085 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AkWGDzW-QMtLIalG1FT3yeoHzBkFrQCDks5tlpuzgaJpZM4TIzKW
.

Please provide additional details and steps to reproduce the issue. Thanks.

Set to "open" on behalf of @Quy by The JTracker Application at issues.joomla.org/joomla-cms/20085

We have been a joomla user for many years.

One of our clients was recently acquired by United Parcel Service (UPS)...

UPS has an in-house security staff that monitors their sites around the
world on a regular basis...

As part of the acquisition of my client, they performed a security scan of
the joomla website that we developed...

We have remediated vulnerabilities in several of the third party modules,
but their in-house scanning tool uncovered a problem on the core contact
form... My engineer thought is was a false positive result, but upon
further discussions with the UPS security team, we saw the problem their
tool highlighted...

Attached is a copy of the SCAN report... It's highly confidential...

If you have any questions, I can be reached by phone at (949) 231-0654
(Los Angeles)

Here is what they (UPS) found...

Requirement(s)

• Do not allow unhandled exceptions
• Disable default error handling
• Upon detection of any error condition
  • Transfer control to a dedicated error handler
  • Log appropriate details per logging standards
  • Notify support team appropriately
  • Send to the client a directive message devoid of system information
  • Set the HTTP response status code and message to the
    most appropriate from the "4xx" family (Reference: "Appropriate
    HTTP Status
    Codes" under "Guidelines")
  • Perform analysis to determine the root cause
• When applicable, patch the system to prevent recurrence of
  the exception

Appropriate HTTP Status Codes

*Reference: *https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

Default (when a more appropriate choice below does not fit):

· HTTP Response Header Status Code: 400

· HTTP Response Header Status Message: Bad Request

User fails to authenticate

· HTTP Response Header Status Code: 401

· HTTP Response Header Status Message: Unauthorized

User attempts to access a private resource

· HTTP Response Header Status Code: 403

· HTTP Response Header Status Message: Forbidden

User attempts to access a resource that does not exist

· HTTP Response Header Status Code: 404

· HTTP Response Header Status Message: Not Found

User attempts to use an invalid HTTP method (i.e. Method tampering or GET
for POST)

· HTTP Response Header Status Code: 405

· HTTP Response Header Status Message: Method Not Allowed

User does not respond to challenge in time allotted

· HTTP Response Header Status Code: 408

· HTTP Response Header Status Message: Request Timeout

User uploads a resource or sends a request that is too large (i.e. Buffer
Overflow, Unrestricted File Upload, etc.)

· HTTP Response Header Status Code: 413

· HTTP Response Header Status Message: Request Entity Too Large

          *User requests a URL that is too long (i.e. Buffer Overflow,

etc.)*

· HTTP Response Header Status Code: 414

· HTTP Response Header Status Message: Request-URI Too Long

User utilizes incorrect media type or uploads a file of an unsupported
media type (i.e. Sending URI-encoded format when SOAP expected, uploading ,
etc.)

· HTTP Response Header Status Code: 415

· HTTP Response Header Status Message: Unsupported Media Type

Here are the next steps:

When the user sends invalid data or otherwise does something wrong,
regrettable or malicious, ensure the application returns a status code that
starts with “4”. Please see the preceding documentation to help chose the
correct status code and message. Please test by observing the HTTP status
code and response. Once all error conditions return the correct status code
and message, please ask for a rescan.

On Thu, Apr 5, 2018 at 9:33 PM, Quy notifications@github.com wrote:

Please provide additional details and steps to reproduce the issue. Thanks.

This comment was created with the J!Tracker Application
https://github.com/joomla/jissues at issues.joomla.org/tracker/
joomla-cms/20085.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#20085 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AkWGD9IQKzpOtE-Kk2bC3dJIJBtkSIgoks5tlvASgaJpZM4TIzKW
.

If you think there is a vulnerability in core, please get in touch with the security strike team https://developer.joomla.org/security.html. But you should not post confidential information in a public issue tracker.

@laoneo
It is fine. The user contacted JSST and as this was not considered as a vulnerability, he was advised to post as issue.

Sorry missed that part.

Because of a lack of detail on this issue, this is in essence what their vulnerability report was groaning over. Long and short is their system wanted a 4xx response in a case we're sending a 500 response.

• An Exception with no error code (PHP defaults it to 0 therefore) is thrown in Joomla\CMS\MVC\Controller\BaseController::getInstance() when a controller cannot be found based on the request's task (in this case the team was testing injection of values for this key), Joomla's error handling layer treats a 0 code Exception as a 500 response; this is acceptable for now, we may want to consider making this a 404 response, either way it is not a 200 response so it's OK for now

The other groan now that I've found it again. When CSRF token validation fails (i.e. JSession::checkToken() or jexit(JText::_('JINVALID_TOKEN'));, we immediately exit the application and send a 200 response.

Because our MVC layer doesn't support task chaining, there isn't an efficient way to "divert" some kind of submit action (typically save or submitting login/contact forms) back to a display task, for UX purposes the "best" action we could take is 302 back to the referring page but this action would still fail vulnerability scanners like the one that was in use. Which to me is acceptable; the system is still correctly performing data validation and correctly failing the submission, it just isn't communicated with the most desired HTTP response code.

Just checking in on the status of the issue we reported...

Is a temporary patch being developed?

• Ed

  ---

  _{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/20085.}

Thank you for raising this issue.

Joomla 3 is now in security only mode with no further bug fixes or new features.

Based on the comment above by mbabker this will now been closed.

cc @zero-24