• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Paul Clapham
  • Jeanne Boyarsky
  • Knute Snortum
Sheriffs:
  • Liutauras Vilda
  • Tim Cooke
  • Junilu Lacar
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Joe Ess
  • salvin francis
  • fred rosenberger

Secure by Design: Securing objects/entities

 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dear authors,

Should domain objects/entities know how to secure itself? Or should a separate service have that responsibility?

Thanks.
 
Ranch Hand
Posts: 438
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If the object has inherent vulnerabilities ,how would passing it to a service help?
What would be the workflow of that strategy ?

It seems to make more sense to check vulnerabilities in Domain objects at design time rather than run time.
 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think it should be a combination of both. The more levels of security, the better. For instance, the domain object could have constraints at the property level and the service could handle different types of exceptions.
 
Author
Posts: 4
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jose

In general it is a powerful idea to use "good design" as far as possible to mitigate the risk for security vulnerabilities. And, one of the most powerful design ideas from object orientation is obviously to "harden" the object itself as much as possible
to ensure it is not used in an insecure way by accident (which is the most common pitfall)

If we talk about entities รก la Domain Driven Design (things that have a "thread of identity that transcends changes in attributes") there are two major ways design can help secure them.

First, teach your entities to speak "domainish" by using Domain Primitives (e g PhoneNumber,  RoomNumber, or BookCount) as their parameters and return types. This relieves them of a lot of "low-level" validation (format, syntax etc) and stops a lot of simple mistakes and attacks.

Second, ensure that your entities are very well aware about the state they are in, and only allow the actions that should be allowed. For example, a plane may only taxi for takeoff if all loaded bags belong to a passenger that has also boarded the plane. Broken state management is the cause of a lot of subtle-to-find security problems.

Chapter 5 speaks about Domain Primitives. Chapter 4 contains a few tricks that are applicable for state management (e g design by contract). Chapter 6 and 7 are dedicated to different aspects of ensuring that an entity is created in a consistent state, and how to handle the complexity that arises from complicated states.

Yours

  Dan
 
Yes, of course, and I accept that blame. In fact, i covet that blame. As does this tiny ad:
Sauce Labs - World's Largest Continuous Testing Cloud for Websites and Mobile Apps
https://coderanch.com/t/722574/Sauce-Labs-World-Largest-Continuous
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!