Some afterthoughts
From: "Jacques Le Roux" <[EMAIL PROTECTED]>
BJ,
The client concern is in case a login/pwd couple is used but not by the right
person (lost, stolen, etc.). Only biometric security
could deal with that I guess.
By limiting the number of time a page can be visited in a period of time you don't really prevent using UI to pull out
confidential
data but you make it so long (years) that it's not usable. It's something used
in spam fighting known as tarpitting. It has proven
to be very efficient and is now used in the gray list concept wich works
great. Anyway for the moment it's the requirement I have
BTW I wonder if it should not better block the account and send a message to the admin in such case. He/she would then be able to
reset the login/pwd to secure anew the login.
I will put the check in at end of RequestHandler.renderView just after the
block where ServerHitBin.countView is used. This would
clearly separate this new security aspect. And having it at the framework level
is clearly easier : you only have to define a list
of pages to constrain by PartyRoles.
Actually it rather should be in RequestHandler.doRequest. Just after the first visit block using an else block. In case a limit
would be reached the eventReturnString would be "lock" and a "lock" response used if present. Then a view would be rendered or more
certainly a request chained to deal with other aspect like sending an email to the admin and finally a view.
Ray, who is also involved in this feature, suggested to use an event. This of course would avoid core framework changes. But I can't
see how to use an event if a required even is already in place.
In the check I will need
. PartyRole(s),
. The list of pages to constrain access by PartyRoles. I will be an
ConstrainViewByRole entity with 2 fields : partyRole viewName
(pages are actually views in OFBiz)
. Max number of page access allowed, and the period of time for counting the
number of page accesses in security.properties
Ray suggested to put also these 2 parameters in the ConstrainViewByRole entity. This would allow a more finely grained solution. So
the fields would be partyRole, viewName, maxViewAllowed and maxViewAllowedDuration
. An AccessedPage entity with fields loginId viewAccessed dateTimeOfAccess.
(note : I changed UrlAccessed to viewAccessed)
I think it's a feature generic enough to be used in Framework if someone is
interested in future (if nothing is defined in
security.properties the block would be simply skipped so it's harmful). So if
nobody see a problem with that I will implement and
commit. Any comments welcome
I replace "if nothing is defined in security.properties the block would be simply skipped" by "if nothing is defined in
ConstrainViewByRole for the current view the block would be simply skipped"
Jacques
Thanks
Jacques
From: "BJ Freeman" <[EMAIL PROTECTED]>
Jacques:
my first reaction is if a robot can pull out confidential data then
ofbiz would not pass the PCI audit.
the focus should be to not allow log in to confidential data, unless a
strict protocol is followed.
The other is to find all the ways a hack can be done, like DOS that may
also allow access into the system.
SATAN (Security Administrator Tool for Analyzing Networks) (1990)test
very thoroughly. using it as a basis of testing would further ofbiz.
http://d4rk-c0de.org/2008/11/15/satan-securitry-administrator/.
Jacques Le Roux sent the following on 12/5/2008 8:25 AM:
I have another requirement : being able to dissalow acces to some pages
for some users if a number of hits in a pre-defined period of time is
exceeded. I have an idea of how to do that but do you thing it could be
interesting to be commited ? Maybe in a more generic way ?
The purpose is security : this would prevent any kind of robot to pull
out confidential data from the system.
Thanks
Jacques
