Skip to main content
fixed small typos
Source Link
Vogel612
  • 25.5k
  • 7
  • 59
  • 141

I have read up that nothing needs to be done for xss in symfony as it is already protected from it, is this case?

The Twig templating engine automatically encodes output variables, which will prevent XSS in most situations, but not all. A simple example is <script>[user_input]</script> or <a href="" onclick="[user_input]">click me</a>.

PHP templates do not encode output, and of course any echoes you perform outside of templates are also not encoded.

If this is not the case I want to make sure that the code I have written below if sufficient enough to protect from xss. Or if there is anything I can do to enhance it to prevent xss attacks.

You don't actually print any variables, so there is no danger of XSS in the code you provided.

Your additional input filter is generally a very good idea (as defense-in-depth; never as only defense; XSS is prevented by encoding output), although I would suggest that you write your own instead of using the filter functions PHP provides. The problem with FILTER_SANITIZE_STRING:

  • It is poorly named. What does sanitize string even mean? This also means that the behavior may be changed in later versions, as it would still fit the name.
  • It is poorly documented. It says this: Strip tags, optionally strip or encode special characters. It does apply strip_tags, but it also encodes ' and " by default, not optionally. < and > on the other hand are not encoded.
  • It changes your input. strip_tags doesn't actually just tripstrip tags. If there is a stray < in the string, it will remove anything afterwards which may cause bugs (I <3 you becomsebecomes I, super<secure_password becomes super).
  • Encoding should happen at the output, not at the input.

I would suggest that you write your own input filter class, which may look something like the linked one.

I have read up that nothing needs to be done for xss in symfony as it is already protected from it, is this case?

The Twig templating engine automatically encodes output variables, which will prevent XSS in most situations, but not all. A simple example is <script>[user_input]</script> or <a href="" onclick="[user_input]">click me</a>.

PHP templates do not encode output, and of course any echoes you perform outside of templates are also not encoded.

If this is not the case I want to make sure that the code I have written below if sufficient enough to protect from xss. Or if there is anything I can do to enhance it to prevent xss attacks.

You don't actually print any variables, so there is no danger of XSS in the code you provided.

Your additional input filter is generally a very good idea (as defense-in-depth; never as only defense; XSS is prevented by encoding output), although I would suggest that you write your own instead of using the filter functions PHP provides. The problem with FILTER_SANITIZE_STRING:

  • It is poorly named. What does sanitize string even mean? This also means that the behavior may be changed in later versions, as it would still fit the name.
  • It is poorly documented. It says this: Strip tags, optionally strip or encode special characters. It does apply strip_tags, but it also encodes ' and " by default, not optionally. < and > on the other hand are not encoded.
  • It changes your input. strip_tags doesn't actually just trip tags. If there is a stray < in the string, it will remove anything afterwards which may cause bugs (I <3 you becomse I, super<secure_password becomes super).
  • Encoding should happen at the output, not at the input.

I would suggest that you write your own input filter class, which may look something like the linked one.

I have read up that nothing needs to be done for xss in symfony as it is already protected from it, is this case?

The Twig templating engine automatically encodes output variables, which will prevent XSS in most situations, but not all. A simple example is <script>[user_input]</script> or <a href="" onclick="[user_input]">click me</a>.

PHP templates do not encode output, and of course any echoes you perform outside of templates are also not encoded.

If this is not the case I want to make sure that the code I have written below if sufficient enough to protect from xss. Or if there is anything I can do to enhance it to prevent xss attacks.

You don't actually print any variables, so there is no danger of XSS in the code you provided.

Your additional input filter is generally a very good idea (as defense-in-depth; never as only defense; XSS is prevented by encoding output), although I would suggest that you write your own instead of using the filter functions PHP provides. The problem with FILTER_SANITIZE_STRING:

  • It is poorly named. What does sanitize string even mean? This also means that the behavior may be changed in later versions, as it would still fit the name.
  • It is poorly documented. It says this: Strip tags, optionally strip or encode special characters. It does apply strip_tags, but it also encodes ' and " by default, not optionally. < and > on the other hand are not encoded.
  • It changes your input. strip_tags doesn't actually just strip tags. If there is a stray < in the string, it will remove anything afterwards which may cause bugs (I <3 you becomes I, super<secure_password becomes super).
  • Encoding should happen at the output, not at the input.

I would suggest that you write your own input filter class, which may look something like the linked one.

Source Link
tim
  • 25.3k
  • 3
  • 31
  • 76

I have read up that nothing needs to be done for xss in symfony as it is already protected from it, is this case?

The Twig templating engine automatically encodes output variables, which will prevent XSS in most situations, but not all. A simple example is <script>[user_input]</script> or <a href="" onclick="[user_input]">click me</a>.

PHP templates do not encode output, and of course any echoes you perform outside of templates are also not encoded.

If this is not the case I want to make sure that the code I have written below if sufficient enough to protect from xss. Or if there is anything I can do to enhance it to prevent xss attacks.

You don't actually print any variables, so there is no danger of XSS in the code you provided.

Your additional input filter is generally a very good idea (as defense-in-depth; never as only defense; XSS is prevented by encoding output), although I would suggest that you write your own instead of using the filter functions PHP provides. The problem with FILTER_SANITIZE_STRING:

  • It is poorly named. What does sanitize string even mean? This also means that the behavior may be changed in later versions, as it would still fit the name.
  • It is poorly documented. It says this: Strip tags, optionally strip or encode special characters. It does apply strip_tags, but it also encodes ' and " by default, not optionally. < and > on the other hand are not encoded.
  • It changes your input. strip_tags doesn't actually just trip tags. If there is a stray < in the string, it will remove anything afterwards which may cause bugs (I <3 you becomse I, super<secure_password becomes super).
  • Encoding should happen at the output, not at the input.

I would suggest that you write your own input filter class, which may look something like the linked one.