| Age | Commit message (Collapse) | Author |
|---|
|
nagios and webapp node (#5096)
|
|
|
|
for custom git source, improve apache config.
|
|
Nagios won't work with setting this option to "DENY",
as set in conf.d/security (#4169). Therefor we allow
it here, only for nagios.
|
|
|
|
|
|
|
|
(fixing #3384)
node name and dns fqdn could be different
Also note that on local deploys that warning from #3384 will continue to exist (because of dns)
|
|
|
|
|
|
more than once in different locations, depending on what services are configured on a node (#3612)
Change-Id: Iff064d3d67baa132fb5198fea741522ab4e71770
|
|
Change-Id: Idd413349ec0b99835a1cbb4fb4c4fcef1a8fdeab
|
|
The LEAP web application can be displayed inside other pages using an HTML
iframe. Therefore, an attacker can embed parts of the LEAP application inside
of a webpage they control. They can then use special style properties to
disguise the embedded page. By tricking a user in to clicking in the iframe, the
attacker can coerce the user in to performing unintended actions within the LEAP
web application.
An attacker creates a website that embeds the LEAP web application in an iframe.
They then create an HTML /JavaScript game on the same page that involves
clicking and dragging sprites. When a user plays the game, they are in fact
dragging new text values in to the ‘‘Change Password’’ form in the LEAP web app,
which is hidden behind the game using
As long as iframe embedding is not required in the normal usage of the
application, the X-Frame-Options header should be added to prevent browsers from
displaying the web application in frames on other origins.
This has also been set in the webapp
Change-Id: I9e26ae32de4b7b6a327196838d0fa410648f107d
|
|
. Disable ServerSignature
. Set ServerTokens Prod
. unset the X-Powered-By and X-Runtime apache headers
Change-Id: Iddb2cb9a0465bc7f657581adaacbbf748479fd7a
|
|
Change-Id: Ia6fc60c0c1fdfa50e1d6d981699c1d8010df63fc
|
|
|
|
|
|
This presents us with an interesting problem of deprecation. We need to manage
the removal of something that we previously installed in any released code. How
long we carry the puppet code that removes raises some interesting questions: do
we require that someone who deployed version 1 (where the apache ssl proxy was
deployed) of the platform upgrade first to version 2 (where we remove the apache
ssl proxy) before they upgrade to version 3 (where the apache ssl proxy removal
is no longer present) -- or do we allow people to skip versions?
|
|
if the node is a monitor node
|
|
for hosting two TLS domains on one IP).
|
|
|
|
|
|
|
|
|
|
configurations
|
|
|
