Repository: wicket Updated Branches: refs/heads/master e72e54f09 -> 4b3f6c9ee
Added documentation for external security checks Project: http://git-wip-us.apache.org/repos/asf/wicket/repo Commit: http://git-wip-us.apache.org/repos/asf/wicket/commit/4b3f6c9e Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/4b3f6c9e Diff: http://git-wip-us.apache.org/repos/asf/wicket/diff/4b3f6c9e Branch: refs/heads/master Commit: 4b3f6c9eeec7183b566ddddcb7344aa47cdf8766 Parents: e72e54f Author: Tobias Soloschenko <[email protected]> Authored: Sun Aug 28 16:43:52 2016 +0200 Committer: Tobias Soloschenko <[email protected]> Committed: Sun Aug 28 16:43:52 2016 +0200 ---------------------------------------------------------------------- .../src/docs/guide/security/security_6.gdoc | 55 +++++++++++++++----- .../src/docs/guide/security/security_7.gdoc | 14 +++++ wicket-user-guide/src/docs/guide/toc.yml | 3 +- 3 files changed, 57 insertions(+), 15 deletions(-) ---------------------------------------------------------------------- http://git-wip-us.apache.org/repos/asf/wicket/blob/4b3f6c9e/wicket-user-guide/src/docs/guide/security/security_6.gdoc ---------------------------------------------------------------------- diff --git a/wicket-user-guide/src/docs/guide/security/security_6.gdoc b/wicket-user-guide/src/docs/guide/security/security_6.gdoc index 4ec812f..bbb0316 100644 --- a/wicket-user-guide/src/docs/guide/security/security_6.gdoc +++ b/wicket-user-guide/src/docs/guide/security/security_6.gdoc @@ -1,14 +1,41 @@ - - - In this chapter we have seen the components and the mechanisms that allow us to implement security policies in our Wicket-based applications. Wicket comes with an out of the box support for both authorization and authentication. - -The central element of authorization mechanism is the interface @IAuthorizationStrategy@ which decouples our components from any detail about security strategy. The implementations of this interface must decide if a user is allowed to instantiate a given page or component and if she/he can perform a given action on it. - -Wicket natively supports role-based authorizations with strategies @MetaDataRoleAuthorizationStrategy@ and @AnnotationsRoleAuthorizationStrategy@. The difference between these two strategies is that the first offers a programmatic approach for role handling while the second promotes a declarative approach using built-in annotations. - -After having explored how Wicket internally implements authentication and authorization, in the last part of the chapter we have learnt how to configure our applications to support HTTPS and how to specify which pages must be served over this protocol. - -In the last paragraph we have seen how Wicket protects package resources with a guard entity that allows us to decide which package resources can be accessed from users. - - - +Since Mozilla released their site to check if web pages have security issues named [Mozilla Observatory|https://observatory.mozilla.org] there are +a few things which can be done to get a high grade within this ranking without using further frameworks. + +Add a request cycle listener to your web application and adjust the headers to fit your requirements: +{code} +@Override +protected void init() +{ + super.init(); + + getRequestCycleListeners().add(new AbstractRequestCycleListener(){ + + @Override + public void onEndRequest(RequestCycle cycle) + { + ((WebResponse)cycle.getResponse()).setHeader("X-XSS-Protection", "1; mode=block"); + ((WebResponse)cycle.getResponse()).setHeader("Strict-Transport-Security", "max-age=31536000;" + + " includeSubDomains; preload"); + ((WebResponse)cycle.getResponse()).setHeader("X-Content-Type-Options", "nosniff"); + ((WebResponse)cycle.getResponse()).setHeader("X-Frame-Options", "DENY"); + ((WebResponse)cycle.getResponse()).setHeader("Content-Security-Policy", "default-src https:"); + } + }); +} +{code} + +Add this configuration to your web.xml (or let your server redirect to https): +{code:xml} +<?xml version="1.0" encoding="UTF-8"?> +<security-constraint> + <web-resource-collection> + <web-resource-name>Entire Application</web-resource-name> + <url-pattern>/*</url-pattern> + </web-resource-collection> + <user-data-constraint> + <transport-guarantee>CONFIDENTIAL</transport-guarantee> + </user-data-constraint> +</security-constraint> +{code} + +After this changes you have to check if your web application continues to work because it fits the requirements given with this header files. For example that resources must not requested from other domains anymore. \ No newline at end of file http://git-wip-us.apache.org/repos/asf/wicket/blob/4b3f6c9e/wicket-user-guide/src/docs/guide/security/security_7.gdoc ---------------------------------------------------------------------- diff --git a/wicket-user-guide/src/docs/guide/security/security_7.gdoc b/wicket-user-guide/src/docs/guide/security/security_7.gdoc new file mode 100644 index 0000000..4ec812f --- /dev/null +++ b/wicket-user-guide/src/docs/guide/security/security_7.gdoc @@ -0,0 +1,14 @@ + + + In this chapter we have seen the components and the mechanisms that allow us to implement security policies in our Wicket-based applications. Wicket comes with an out of the box support for both authorization and authentication. + +The central element of authorization mechanism is the interface @IAuthorizationStrategy@ which decouples our components from any detail about security strategy. The implementations of this interface must decide if a user is allowed to instantiate a given page or component and if she/he can perform a given action on it. + +Wicket natively supports role-based authorizations with strategies @MetaDataRoleAuthorizationStrategy@ and @AnnotationsRoleAuthorizationStrategy@. The difference between these two strategies is that the first offers a programmatic approach for role handling while the second promotes a declarative approach using built-in annotations. + +After having explored how Wicket internally implements authentication and authorization, in the last part of the chapter we have learnt how to configure our applications to support HTTPS and how to specify which pages must be served over this protocol. + +In the last paragraph we have seen how Wicket protects package resources with a guard entity that allows us to decide which package resources can be accessed from users. + + + http://git-wip-us.apache.org/repos/asf/wicket/blob/4b3f6c9e/wicket-user-guide/src/docs/guide/toc.yml ---------------------------------------------------------------------- diff --git a/wicket-user-guide/src/docs/guide/toc.yml b/wicket-user-guide/src/docs/guide/toc.yml index 04951e1..71c19c9 100644 --- a/wicket-user-guide/src/docs/guide/toc.yml +++ b/wicket-user-guide/src/docs/guide/toc.yml @@ -178,7 +178,8 @@ security: security_3: Using HTTPS protocol security_4: URLs encryption in detail security_5: Package Resource Guard - security_6: Summary + security_6: External Security Checks + security_7: Summary testing: title: Test Driven Development with Wicket testing_1: Utility class WicketTester
