Project

General

Profile

Actions

Bug #36161

open

Include current Domain Model UID in calculated HMAC

Added by Nico de Haen about 12 years ago. Updated over 8 years ago.

Status:
New
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 over 11 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 about 11 years ago

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

Updated by Alexander Schnitzler almost 11 years ago

  • Status changed from New to Needs Feedback

Is this still necessary at all?

Actions #4

Updated by Nico de Haen almost 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 almost 11 years ago

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

Updated by Alexander Opitz over 9 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 over 9 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 over 9 years ago

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

Updated by Benni Mack almost 9 years ago

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

Updated by Susanne Moog over 8 years ago

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

Updated by Benni Mack over 8 years ago

  • Target version deleted (7.5)
Actions

Also available in: Atom PDF