Page History

...

Even if all of the digital materials stored in your DSpace archive
are available for open access by the world, you still need some security. At the very least, you probably don't want everyone visiting
the site to be able to add to, modify, and delete the contents of the archive.

Some archives contain materials that should only be visible to a select
audience. Those sites can use the the usual DSpace access-control mechanism
to grant "read" privileges to certain users and groups.

Even if your archive is relatively open,
you still need to consider the security of the login process for your EPeople,
as described in the
next section.

Practical Security Solutions

...

Security people have a term, threat model, which describes the threats and risks
of compromise (disclosure of confidential information) you expect
to encounter.
In the case of a network service like a Web server, the threats you should
realistically expect include:

...

Note that I'm not mentioning the many other types of threats
because the solutions are not discussed here –
e.g. denial-of-service attacks, SQL injection, etc.

...

When do we have to worry about the contents of packets on the network
being seen by a third party? Typically, only when the user is entering
a password, such as on the login page and the administrative page
where the password is changed.

The solution is to force the Web transactions containing a password to
be encrypted. Assuming we are only concerned about pages with HTML
forms, the simplest way to force encryption is to force the pages
containing the password forms to be downloaded with HTTPS. If the browser
tries to load that page with HTTP, the server should redirect it
to the equivalent HTTPS URL.

Note that it isn't strictly necessary to load the form pagewith HTTPS; the form itself can be transmitted
unencrypted since it doesn't contain a password at that time, only when
the form is filled in and POSTed to the server. However, the form tag
typically has an action attribute containing a relative URL,
so on submission, it gets sent to whatever host and port were on the
page that got loaded. Thus the page has to be loaded with HTTPS.

If you change the UI code so the password forms always use HTTPS URLs,
then it is not necessary to use the redirect technique above.

...

DSpace establishes a login session, which identifies your EPerson,
by handing your browser a cookie.
The cookie is not marked secure so it gets transmitted on non-encrypted
connections, so it is subject to being observed and "stolen".
So, the threat model
is that an attacker could steal your cookie and get your level of access
to DSpace, which is significant if you're an Administrator.

As of DSpace Release 1.4.1, this risk has been greatly mitigated
because the Authenticate class now binds a session to the client's
IP address. If a client on a different IP address presents that same
session cookie, it is rejected with an error. This is not foolproof,
since it is possible to spoof IP addresses, but that is a very
sophisticated attack that you may not ever expect to have deployed
against your DSpace archive.

If you are that concerned about session stealing, it's probably worth
requiring encryption on all transactions on your web server.
We expect this to be an unusual case.

...

This really comes down to answering the question "where do I need to
enforce HTTPS on Web transactions".

...