Clone Tools
  • last updated a few minutes ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Improved: Prevent FreeMarker Template Injection (SSTI)

(OFBIZ-11709)

Fixes all the conflicts previously handled by hand (no merge was possible)

Improved: Prevent FreeMarker Template Injection (SSTI)

(OFBIZ-11709)

Some people may want to use another TemplateClassResolver than SAFER_RESOLVER

This creates a new templateClassResolver security property and uses it in

FreeMarkerWorker::makeConfiguration by default

Conflicts all handled by hand (no merge possible)

  1. … 1 more file in changeset.
Improved: Prevent FreeMarker Template Injection (SSTI)

(OFBIZ-11709)

Some people may want to use another TemplateClassResolver than SAFER_RESOLVER

This creates a new templateClassResolver security property and uses it in

FreeMarkerWorker::makeConfiguration by default

Conflicts handled by hand

framework/security/config/security.properties

  1. … 1 more file in changeset.
Improved: Prevent FreeMarker Template Injection (SSTI)

(OFBIZ-11709)

Some people may want to use another TemplateClassResolver than SAFER_RESOLVER

This creates a new templateClassResolver security property and uses it in

FreeMarkerWorker::makeConfiguration by default

  1. … 1 more file in changeset.
Fixed: Prevent FreeMarker Template Injection (SSTI)

(OFBIZ-11709)

Since Freemarker 2.3.17 a known solution to these issues is to register a

TemplateClassResolver in Freemarker configuration in order to limit which

TemplateModels can be instantiated in the templates. The predefined resolver

SAFER_RESOLVER doesn't allow to instantiate the Execute class[4].

So the solution is to add the line

newConfig.setNewBuiltinClassResolver(TemplateClassResolver.SAFER_RESOLVER);

in FreeMarkerWorker.java

Fixed: Prevent FreeMarker Template Injection (SSTI)

(OFBIZ-11709)

Since Freemarker 2.3.17 a known solution to these issues is to register a

TemplateClassResolver in Freemarker configuration in order to limit which

TemplateModels can be instantiated in the templates. The predefined resolver

SAFER_RESOLVER doesn't allow to instantiate the Execute class[4].

So the solution is to add the line

newConfig.setNewBuiltinClassResolver(TemplateClassResolver.SAFER_RESOLVER);

in FreeMarkerWorker.java

Fixed: Prevent FreeMarker Template Injection (SSTI)

(OFBIZ-11709)

Since Freemarker 2.3.17 a known solution to these issues is to register a

TemplateClassResolver in Freemarker configuration in order to limit which

TemplateModels can be instantiated in the templates. The predefined resolver

SAFER_RESOLVER doesn't allow to instantiate the Execute class[4].

So the solution is to add the line

newConfig.setNewBuiltinClassResolver(TemplateClassResolver.SAFER_RESOLVER);

in FreeMarkerWorker.java

Conflicts handled by hand

Fixed: Issue with opening a page via bookmark when the user is logged out (OFBIZ-10539)

Thanks: Ritesh Kumar for report and the patch and Girish for the review.

Fixed: Issue with opening a page via bookmark when the user is logged out (OFBIZ-10539)

Thanks: Ritesh Kumar for report and the patch and Girish for the review.

Fixed: Issue with opening a page via bookmark when the user is logged out (OFBIZ-10539)

Thanks: Ritesh Kumar for report and the patch and Girish for the review.

Improved: Improve ObjectInputStream class

(OFBIZ-10837)

While working on OFBIZ-11633 I crossed an issue in R18 (not in trunk) where

objects from org.apache.commons.fileupload (namely DiskFileItem and

FileItemHeadersImpl) are not serializable.

While at it I decided to handle at the SafeObjectInputStream level

the "fileItems" case I already crossed with, OFBIZ-11534, in RequestHandler

It has an inconvenient in R18 (not in trunk) where ObjectInputStream can't

handle a null class (of course) and so return a benign exception in log (only).

I believe it's better to handle these specific cases at the lower possible

level in all supported branches.

  1. … 1 more file in changeset.
Improved: Improve ObjectInputStream class

(OFBIZ-10837)

While working on OFBIZ-11633 I crossed an issue in R18 (not in trunk) where

objects from org.apache.commons.fileupload (namely DiskFileItem and

FileItemHeadersImpl) are not serializable.

While at it I decided to handle at the SafeObjectInputStream level

the "fileItems" case I already crossed with, OFBIZ-11534, in RequestHandler

It has an inconvenient in R18 (not in trunk) where ObjectInputStream can't

handle a null class (of course) and so return a benign exception in log (only).

I believe it's better to handle these specific cases at the lower possible

level in all supported branches.

  1. … 1 more file in changeset.
Improved: Improve ObjectInputStream class

(OFBIZ-10837)

While working on OFBIZ-11633 I crossed an issue in R18 (not in trunk) where

objects from org.apache.commons.fileupload (namely DiskFileItem and

FileItemHeadersImpl) are not serializable.

While at it I decided to handle at the SafeObjectInputStream level

the "fileItems" case I already crossed with, OFBIZ-11534, in RequestHandler

It has an inconvenient in R18 (not in trunk) where ObjectInputStream can't

handle a null class (of course) and so return a benign exception in log (only).

I believe it's better to handle these specific cases at the lower possible

level in all supported branches.

  1. … 1 more file in changeset.
Improved: Increase the size of http.upload.max.sizethreshold

(OFBIZ-11598)

That's rather refactoring to avoid to have the size hardcoded in several places

Next: ask if it's OK for everyone to increase the size

  1. … 2 more files in changeset.
Documented: Framework, migration all docbook files to asciidoc (OFBIZ-11587)

- common-sending-email: include in email

- datafile: move as a include at the end of entity-engine section

- entity-engine: list of link to OFBiz wiki about entity configuration

- service-engine: a link to OFBiz wiki Service Engine Guide

- webtools: help for main screen

- mini-lang: include a link to OFBiz wiki mini-lang-reference at the

beginning of minilang-to-groovy-manual

move minilang-to-groovy-manual to Development environment

section

- unit-test: include as Junit test, and use README to list gradle

command available (so add a tag in REAME.adoc)

- base: add a link to OFBiz wiki Configuration Guide, in deployment

section

- SingleSignOn with LDAP: move to plugin LDAP and include in deployment

section

developer-manual is updated with some include lines or with directly a

sentence.

    • -0
    • +28
    ./src/docs/asciidoc/_include/email-sending.adoc
  1. … 9 more files in changeset.
Documented: Framework/base migration to asciidoc (OFBIZ-11587)

Delete docbook files

Documented: Framework/base migration to asciidoc (OFBIZ-11587)

only one file about receiving email, so create email.adoc which included

receiving and later sending.

email.adoc is included in developer-manual.adoc in deployment section

    • -0
    • +39
    ./src/docs/asciidoc/_include/email-receiving.adoc
    • -0
    • +23
    ./src/docs/asciidoc/email.adoc
  1. … 1 more file in changeset.
Improved: replaces module by MODULE everywhere

  1. … 670 more files in changeset.
Fixed: Prevent Host Header Injection (CVE-2019-12425)

(OFBIZ-11583)

  1. … 2 more files in changeset.
Fixed: Prevent Host Header Injection (CVE-2019-12425)

(OFBIZ-11583)

Conflicts handled by hand

framework/security/config/security.properties

framework/webapp/src/main/java/org/apache/ofbiz/webapp/control/RequestHandler.java

  1. … 2 more files in changeset.
Fixed: Prevent Host Header Injection (CVE-2019-12425)

(OFBIZ-11583)

  1. … 2 more files in changeset.
Fixed: The createTaskContent request does not work

(OFBIZ-11246)

It seems that same request can not be parsed multiple times if it has multi part

object in it as the parse method remove it after that.

Found one stackoverflow link around the same:

https://stackoverflow.com/questions/13881272/

servletfileuploadparserequestrequest-returns-an-empty-list

I believe that all places/uploads using this workflow should resulting the same

issue.

One possible solution I could think of without going with new approach is to set

list of file Items into the request attribute and use it if parse method remove

it and unable to retrieve on 2nd call.

Thanks: Ankush Upadhyay for the analysis and initial patch. I only slightly

modified it.

  1. … 1 more file in changeset.
Fixed: The createTaskContent request does not work

(OFBIZ-11246)

It seems that same request can not be parsed multiple times if it has multi part

object in it as the parse method remove it after that.

Found one stackoverflow link around the same:

https://stackoverflow.com/questions/13881272/

servletfileuploadparserequestrequest-returns-an-empty-list

I believe that all places/uploads using this workflow should resulting the same

issue.

One possible solution I could think of without going with new approach is to set

list of file Items into the request attribute and use it if parse method remove

it and unable to retrieve on 2nd call.

Thanks: Ankush Upadhyay for the analysis and initial patch. I only slightly

modified it.

  1. … 1 more file in changeset.
Fixed: The createTaskContent request does not work

(OFBIZ-11246)

It seems that same request can not be parsed multiple times if it has multi part

object in it as the parse method remove it after that.

Found one stackoverflow link around the same:

https://stackoverflow.com/questions/13881272/

servletfileuploadparserequestrequest-returns-an-empty-list

I believe that all places/uploads using this workflow should resulting the same

issue.

One possible solution I could think of without going with new approach is to set

list of file Items into the request attribute and use it if parse method remove

it and unable to retrieve on 2nd call.

Thanks: Ankush Upadhyay for the analysis and initial patch. I only slightly

modified it.

  1. … 1 more file in changeset.
Fixed: The createTaskContent request does not work

(OFBIZ-11246)

It seems that same request can not be parsed multiple times if it has multi part

object in it as the parse method remove it after that.

Found one stackoverflow link around the same:

https://stackoverflow.com/questions/13881272/

servletfileuploadparserequestrequest-returns-an-empty-list

I believe that all places/uploads using this workflow should resulting the same

issue.

One possible solution I could think of without going with new approach is to set

list of file Items into the request attribute and use it if parse method remove

it and unable to retrieve on 2nd call.

Thanks: Ankush Upadhyay for the analysis and initial patch. I only slightly

modified it.

  1. … 1 more file in changeset.
Fixed: Ensure that the SameSite attribute is set to 'strict' for all cookies.

(OFBIZ-11470)

As reported by OWASP ZAP:

A cookie has been set without the SameSite attribute, which means that the

cookie can be sent as a result of a 'cross-site' request. The SameSite attribute

is an effective counter measure to cross-site request forgery, cross-site script

inclusion, and timing attacks.

The solution was not obvious in OFBiz for 2 reasons:

1. There is no HttpServletResponse::setHeader. So we need to use a filter

(SameSiteFilter) and even that is not enough because of 2:

2. To prevent session fixation we force Tomcat to generates a new jsessionId,

ultimately put in cookie, in LoginWorker::login. So we need to add a call to

SameSiteFilter::addSameSiteCookieAttribute in

UtilHttp::setResponseBrowserDefaultSecurityHeaders.

  1. … 15 more files in changeset.
Fixed: Ensure that the SameSite attribute is set to 'strict' for all cookies.

(OFBIZ-11470)

As reported by OWASP ZAP:

A cookie has been set without the SameSite attribute, which means that the

cookie can be sent as a result of a 'cross-site' request. The SameSite attribute

is an effective counter measure to cross-site request forgery, cross-site script

inclusion, and timing attacks.

The solution was not obvious in OFBiz for 2 reasons:

1. There is no HttpServletResponse::setHeader. So we need to use a filter

(SameSiteFilter) and even that is not enough because of 2:

2. To prevent session fixation we force Tomcat to generates a new jsessionId,

ultimately put in cookie, in LoginWorker::login. So we need to add a call to

SameSiteFilter::addSameSiteCookieAttribute in

UtilHttp::setResponseBrowserDefaultSecurityHeaders.

  1. … 15 more files in changeset.
Fixed: Ensure that the SameSite attribute is set to 'strict' for all cookies.

(OFBIZ-11470)

As reported by OWASP ZAP:

A cookie has been set without the SameSite attribute, which means that the

cookie can be sent as a result of a 'cross-site' request. The SameSite attribute

is an effective counter measure to cross-site request forgery, cross-site script

inclusion, and timing attacks.

The solution was not obvious in OFBiz for 2 reasons:

1. There is no HttpServletResponse::setHeader. So we need to use a filter

(SameSiteFilter) and even that is not enough because of 2:

2. To prevent session fixation we force Tomcat to generates a new jsessionId,

ultimately put in cookie, in LoginWorker::login. So we need to add a call to

SameSiteFilter::addSameSiteCookieAttribute in

UtilHttp::setResponseBrowserDefaultSecurityHeaders.

  1. … 15 more files in changeset.
Fixed: Ensure that the SameSite attribute is set to 'strict' for all cookies.

(OFBIZ-11470)

As reported by OWASP ZAP:

A cookie has been set without the SameSite attribute, which means that the

cookie can be sent as a result of a 'cross-site' request. The SameSite attribute

is an effective counter measure to cross-site request forgery, cross-site script

inclusion, and timing attacks.

The solution was not obvious in OFBiz for 2 reasons:

1. There is no HttpServletResponse::setHeader. So we need to use a filter

(SameSiteFilter) and even that is not enough because of 2:

2. To prevent session fixation we force Tomcat to generates a new jsessionId,

ultimately put in cookie, in LoginWorker::login. So we need to add a call to

SameSiteFilter::addSameSiteCookieAttribute in

UtilHttp::setResponseBrowserDefaultSecurityHeaders.

  1. … 15 more files in changeset.
Improved: Upgrade Freemarker from 2.3.29 to 2.3.30.

(OFBIZ-11445)

  1. … 1 more file in changeset.