Project

General

Profile

Actions

Bug #36161

closed

Include current Domain Model UID in calculated HMAC

Added by Nico de Haen over 12 years ago. Updated 5 months ago.

Status:
Rejected
Priority:
Should have
Assignee:
Category:
Extbase
Target version:
-
Start date:
2012-04-16
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
6.2
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

We discussed this already at T3DD12.
The calculated HMAC does not take the current domain model UID in account as one would assume, if there is a HMAC form verification.

Actions #1

Updated by Alexander Schnitzler almost 12 years ago

  • Assignee set to Helmut Hummel
  • Target version set to Extbase 6.1

@Helmut: I assigned this to you as I heard you will work on the security for 6.1. Feel free to change this if I am wrong.

Actions #2

Updated by Alexander Schnitzler over 11 years ago

  • Target version changed from Extbase 6.1 to Extbase 6.2
Actions #3

Updated by Alexander Schnitzler over 11 years ago

  • Status changed from New to Needs Feedback

Is this still necessary at all?

Actions #4

Updated by Nico de Haen over 11 years ago

Well it depends, I consider it an unexpected behavior, if a form is validated by the framework, based on a calculated hash, but the uid can simply be exchanged to any other UID.
In FLOW this is not a problem, since it uses UUIDs, but in extbase it misleads developers to write unsecure code...

Actions #5

Updated by Anja Leichsenring over 11 years ago

  • Target version changed from Extbase 6.2 to Extbase 6.3
Actions #6

Updated by Alexander Opitz about 10 years ago

  • Project changed from 534 to TYPO3 Core
  • Category changed from Extbase: Security to Extbase
  • Status changed from Needs Feedback to New
  • Target version changed from Extbase 6.3 to 7.0
  • TYPO3 Version set to 6.2
  • Is Regression set to No
Actions #7

Updated by Helmut Hummel about 10 years ago

Some thoughts on this one:

This will be hard to implement as the mapping happens in PersistenObjectTypeConverter.

If we add a hmac check there, the type converter will not be generic any more and cannot be used without the hmac being present.
If we make the hmac check optional, then the developer still needs to take action (configuring the type converter to do an hmac check)

Currently I have no idea how to make this secure by default.

Actions #8

Updated by Mathias Schreiber almost 10 years ago

  • Target version changed from 7.0 to 7.1 (Cleanup)
Actions #9

Updated by Benni Mack over 9 years ago

  • Target version changed from 7.1 (Cleanup) to 7.4 (Backend)
Actions #10

Updated by Susanne Moog over 9 years ago

  • Target version changed from 7.4 (Backend) to 7.5
Actions #11

Updated by Benni Mack about 9 years ago

  • Target version deleted (7.5)
Actions #12

Updated by Benni Mack 5 months ago

  • Status changed from New to Rejected

I am closing this issue, because I feel like no one is picking this up, I personally don't think it's worth pursuing anymore.

If you are interested in this topic, let me know, and I will re-open the ticket. You can also open a new ticket.

Actions

Also available in: Atom PDF