Summary
The snippet code located at /app/models/concerns/rdf/object.rb#L68-L72 is vulnerable to a Post-Unicode normalization issue (CWE-176). Such a vulnerability happens when a logical validation or a security check is performed before a Unicode normalization. The Unicode character equivalent of a character would resurface after the normalization.
Details
Please check the reference for further details on how this vulnerability happens.
PoC
In a little adapted excerpt of the code snippet. Please run the following PoC.
require "unf"
require "active_support/all"
def normalize_name(name)
return if name.blank?
# name must be NFKC
name = UNF::Normalizer.normalize(name.strip, :nfkc)
end
# Case 1: valid
name = "\t\n\v\f\r s \x00\ "
puts "BEFORE: [#{name}]"
name = normalize_name(name)
puts "AFTER: [#{name}] #{name.include? " "}"
# Case 2: not valid
name = " s " # surround s with some Unicode whitespace characters.
puts "BEFORE: [#{name}]"
name = normalize_name(name)
puts "AFTER: [#{name}] #{name.include? " "}"
# Case 3: not valid
name = " "
puts "BEFORE: [#{name}]"
name = normalize_name(name)
puts "AFTER: [#{name}] #{name.nil?}"
You can notice that in case:
- Case 1: the stripping of the whitespaces was successful.
- Case 2: surrounding the character
s
with one of the Unicode characters: U+00A0 U+2000 U+2001 U+2002 U+2003 U+2004 U+2005 U+2006 U+2007 U+2008 U+2009 U+200A U+202F U+205F U+3000
would results in the name containing a regular space U+0020
.
- Case 3: If ever the
name
holds only the previous Unicode characters, it would become nil
after the check of return if name.blank?
.
Impact
There is two possible impacts. After the call to normalize_name()
, the name
either results in a nil
thus bypassing the check return if name.blank?
or the name
contains none-stripped whitespaces.
Mitigation
The fix is initially performing the Unicode normalization and then strip for all whitespaces and finally check for a blank string if ever.
References
Summary
The snippet code located at /app/models/concerns/rdf/object.rb#L68-L72 is vulnerable to a Post-Unicode normalization issue (CWE-176). Such a vulnerability happens when a logical validation or a security check is performed before a Unicode normalization. The Unicode character equivalent of a character would resurface after the normalization.
Details
Please check the reference for further details on how this vulnerability happens.
PoC
In a little adapted excerpt of the code snippet. Please run the following PoC.
You can notice that in case:
s
with one of the Unicode characters:U+00A0 U+2000 U+2001 U+2002 U+2003 U+2004 U+2005 U+2006 U+2007 U+2008 U+2009 U+200A U+202F U+205F U+3000
would results in the name containing a regular spaceU+0020
.name
holds only the previous Unicode characters, it would becomenil
after the check ofreturn if name.blank?
.Impact
There is two possible impacts. After the call to
normalize_name()
, thename
either results in anil
thus bypassing the checkreturn if name.blank?
or thename
contains none-stripped whitespaces.Mitigation
The fix is initially performing the Unicode normalization and then strip for all whitespaces and finally check for a blank string if ever.
References