python: minimal CSRF implementation

[yoff]

Only handles django projects. Criteria are:

• custom middleware without CSRF protection, but with authentication
• no local proaction of functions via decorators
• test code is disregarded

This is expressed via concepts, specifically the CsrfProtectionSetting concept is copied from Ruby to allow sharing down the road. I added the CsrfLocalProtection concept to tighten the query.

[yoff]

Evaluation looks fine.

[RasmusWL]

besides the in-line comments, can we move the new concepts to HTTP::Server? (that seems most appropriate)

[RasmusWL]

do we benefit from this true/false result, or could it be a plain predicate csrfEnabled()? (a bit of a nitpick)

[yoff]

This was copied from Ruby, but I think a predicate would work just as well and am happy to change it. We can unify now or once we try to share.

[RasmusWL]

Ok. Then it would be good to align with ruby on this, since the 3-state of true/false/none() could be important for them (such as app.setCsrfEnabled(<unknown value>)) -- maybe that IS actually a good thing to be able to model from the get go. I think it is, so ignore this comment ✔️

[RasmusWL]

Since request handlers can also be made exempt from CSRF with a decorator (see https://docs.djangoproject.com/en/4.0/ref/csrf/#django.views.decorators.csrf.csrf_exempt), I think it would be better if this concept would capture that the CSRF protection was changed, and whether it is now enabled/disabled.

This also means we need to change the predicate that gets the request handler(s) affected.

Suggested change

	/**
	* Gets a `Function` representing the protected interaction
	* (probably a request handler).
	*/
	Function getProtected() { result = super.getProtected() }
	/**
	* Gets a request handler whose CSRF protection is changed.
	*/
	Function getRequestHandler() { result = super.getProtected() }

You initially said "probably a request handler", are there any cases where you would care to change CSRF protection that is NOT a request handler? 😕

[yoff]

That is a good point, this concept should be broader.
I would expect that we only put such decorators on request handlers, but do we want to require that our request handler concept includes the function?

[RasmusWL]

I would expect that we only put such decorators on request handlers, but do we want to require that our request handler concept includes the function?

No. I would expect that only a few request handlers have their CSRF settings manually changed, so I think it's fine to have it like this. (with the changes I suggested)

[github-actions]

QHelp previews:

python/ql/src/Security/CWE-352/CSRFProtectionDisabled.qhelp

CSRF protection weakened or disabled

Cross-site request forgery (CSRF) is a type of vulnerability in which an attacker is able to force a user to carry out an action that the user did not intend.

The attacker tricks an authenticated user into submitting a request to the web application. Typically this request will result in a state change on the server, such as changing the user's password. The request can be initiated when the user visits a site controlled by the attacker. If the web application relies only on cookies for authentication, or on other credentials that are automatically included in the request, then this request will appear as legitimate to the server.

A common countermeasure for CSRF is to generate a unique token to be included in the HTML sent from the server to a user. This token can be used as a hidden field to be sent back with requests to the server, where the server can then check that the token is valid and associated with the relevant user session.

Recommendation

In many web frameworks, CSRF protection is enabled by default. In these cases, using the default configuration is sufficient to guard against most CSRF attacks.

Example

The following example shows a case where CSRF protection is disabled by overriding the default middleware stack and not including the one protecting against CSRF.

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    # 'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
]

The protecting middleware was probably commented out during a testing phase, when server-side token generation was not set up. Simply commenting it back in will enable CSRF protection.

References

• Wikipedia: Cross-site request forgery
• OWASP: Cross-site request forgery
• Common Weakness Enumeration: CWE-352.

ruby/ql/src/queries/security/cwe-352/CSRFProtectionDisabled.qhelp

CSRF protection weakened or disabled

Cross-site request forgery (CSRF) is a type of vulnerability in which an attacker is able to force a user to carry out an action that the user did not intend.

The attacker tricks an authenticated user into submitting a request to the web application. Typically this request will result in a state change on the server, such as changing the user's password. The request can be initiated when the user visits a site controlled by the attacker. If the web application relies only on cookies for authentication, or on other credentials that are automatically included in the request, then this request will appear as legitimate to the server.

A common countermeasure for CSRF is to generate a unique token to be included in the HTML sent from the server to a user. This token can be used as a hidden field to be sent back with requests to the server, where the server can then check that the token is valid and associated with the relevant user session.

Recommendation

In many web frameworks, CSRF protection is enabled by default. In these cases, using the default configuration is sufficient to guard against most CSRF attacks.

Example

The following example shows a case where CSRF protection is disabled by skipping token verification.

class UsersController < ApplicationController
  skip_before_action :verify_authenticity_token
end

Verification can be re-enabled by removing the call to skip_before_action.

Care should be taken when using the Rails protect_from_forgery method to prevent CSRF. The default behaviour of this method is to null the session when an invalid CSRF token is provided. This may not be sufficient to avoid a CSRF vulnerability - for example if parts of the session are memoized. Calling protect_from_forgery with: :exception can help to avoid this by raising an exception on an invalid CSRF token instead.

References

• Wikipedia: Cross-site request forgery
• OWASP: Cross-site request forgery
• Securing Rails Applications: Cross-Site Request Forgery (CSRF)
• Veracode: When Rails' protect_from_forgery Fails.
• Common Weakness Enumeration: CWE-352.

[github-actions]

QHelp previews:

python/ql/src/Security/CWE-352/CSRFProtectionDisabled.qhelp

CSRF protection weakened or disabled

Cross-site request forgery (CSRF) is a type of vulnerability in which an attacker is able to force a user to carry out an action that the user did not intend.

The attacker tricks an authenticated user into submitting a request to the web application. Typically this request will result in a state change on the server, such as changing the user's password. The request can be initiated when the user visits a site controlled by the attacker. If the web application relies only on cookies for authentication, or on other credentials that are automatically included in the request, then this request will appear as legitimate to the server.

A common countermeasure for CSRF is to generate a unique token to be included in the HTML sent from the server to a user. This token can be used as a hidden field to be sent back with requests to the server, where the server can then check that the token is valid and associated with the relevant user session.

Recommendation

In many web frameworks, CSRF protection is enabled by default. In these cases, using the default configuration is sufficient to guard against most CSRF attacks.

Example

The following example shows a case where CSRF protection is disabled by overriding the default middleware stack and not including the one protecting against CSRF.

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    # 'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
]

The protecting middleware was probably commented out during a testing phase, when server-side token generation was not set up. Simply commenting it back in will enable CSRF protection.

References

• Wikipedia: Cross-site request forgery
• OWASP: Cross-site request forgery
• Common Weakness Enumeration: CWE-352.

ruby/ql/src/queries/security/cwe-352/CSRFProtectionDisabled.qhelp

CSRF protection weakened or disabled

Cross-site request forgery (CSRF) is a type of vulnerability in which an attacker is able to force a user to carry out an action that the user did not intend.

The attacker tricks an authenticated user into submitting a request to the web application. Typically this request will result in a state change on the server, such as changing the user's password. The request can be initiated when the user visits a site controlled by the attacker. If the web application relies only on cookies for authentication, or on other credentials that are automatically included in the request, then this request will appear as legitimate to the server.

A common countermeasure for CSRF is to generate a unique token to be included in the HTML sent from the server to a user. This token can be used as a hidden field to be sent back with requests to the server, where the server can then check that the token is valid and associated with the relevant user session.

Recommendation

In many web frameworks, CSRF protection is enabled by default. In these cases, using the default configuration is sufficient to guard against most CSRF attacks.

Example

The following example shows a case where CSRF protection is disabled by skipping token verification.

class UsersController < ApplicationController
  skip_before_action :verify_authenticity_token
end

Verification can be re-enabled by removing the call to skip_before_action.

Care should be taken when using the Rails protect_from_forgery method to prevent CSRF. The default behaviour of this method is to null the session when an invalid CSRF token is provided. This may not be sufficient to avoid a CSRF vulnerability - for example if parts of the session are memoized. Calling protect_from_forgery with: :exception can help to avoid this by raising an exception on an invalid CSRF token instead.

References

• Wikipedia: Cross-site request forgery
• OWASP: Cross-site request forgery
• Securing Rails Applications: Cross-Site Request Forgery (CSRF)
• Veracode: When Rails' protect_from_forgery Fails.
• Common Weakness Enumeration: CWE-352.

[yoff]

force pushed to skip the TestModule, the last two commits will have new shas.

[RasmusWL]

Besides an extended comment, and discussion about the value to use for @precision, this all looks good to me 👍

[github-actions]

QHelp previews:

python/ql/src/Security/CWE-352/CSRFProtectionDisabled.qhelp

CSRF protection weakened or disabled

Cross-site request forgery (CSRF) is a type of vulnerability in which an attacker is able to force a user to carry out an action that the user did not intend.

The attacker tricks an authenticated user into submitting a request to the web application. Typically this request will result in a state change on the server, such as changing the user's password. The request can be initiated when the user visits a site controlled by the attacker. If the web application relies only on cookies for authentication, or on other credentials that are automatically included in the request, then this request will appear as legitimate to the server.

A common countermeasure for CSRF is to generate a unique token to be included in the HTML sent from the server to a user. This token can be used as a hidden field to be sent back with requests to the server, where the server can then check that the token is valid and associated with the relevant user session.

Recommendation

In many web frameworks, CSRF protection is enabled by default. In these cases, using the default configuration is sufficient to guard against most CSRF attacks.

Example

The following example shows a case where CSRF protection is disabled by overriding the default middleware stack and not including the one protecting against CSRF.

MIDDLEWARE = [
    'django.middleware.security.SecurityMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.middleware.common.CommonMiddleware',
    # 'django.middleware.csrf.CsrfViewMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.contrib.messages.middleware.MessageMiddleware',
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
]

The protecting middleware was probably commented out during a testing phase, when server-side token generation was not set up. Simply commenting it back in will enable CSRF protection.

References

• Wikipedia: Cross-site request forgery
• OWASP: Cross-site request forgery
• Common Weakness Enumeration: CWE-352.

ruby/ql/src/queries/security/cwe-352/CSRFProtectionDisabled.qhelp

CSRF protection weakened or disabled

Cross-site request forgery (CSRF) is a type of vulnerability in which an attacker is able to force a user to carry out an action that the user did not intend.

The attacker tricks an authenticated user into submitting a request to the web application. Typically this request will result in a state change on the server, such as changing the user's password. The request can be initiated when the user visits a site controlled by the attacker. If the web application relies only on cookies for authentication, or on other credentials that are automatically included in the request, then this request will appear as legitimate to the server.

A common countermeasure for CSRF is to generate a unique token to be included in the HTML sent from the server to a user. This token can be used as a hidden field to be sent back with requests to the server, where the server can then check that the token is valid and associated with the relevant user session.

Recommendation

In many web frameworks, CSRF protection is enabled by default. In these cases, using the default configuration is sufficient to guard against most CSRF attacks.

Example

The following example shows a case where CSRF protection is disabled by skipping token verification.

class UsersController < ApplicationController
  skip_before_action :verify_authenticity_token
end

Verification can be re-enabled by removing the call to skip_before_action.

Care should be taken when using the Rails protect_from_forgery method to prevent CSRF. The default behaviour of this method is to null the session when an invalid CSRF token is provided. This may not be sufficient to avoid a CSRF vulnerability - for example if parts of the session are memoized. Calling protect_from_forgery with: :exception can help to avoid this by raising an exception on an invalid CSRF token instead.

References

• Wikipedia: Cross-site request forgery
• OWASP: Cross-site request forgery
• Securing Rails Applications: Cross-Site Request Forgery (CSRF)
• Veracode: When Rails' protect_from_forgery Fails.
• Common Weakness Enumeration: CWE-352.

[RasmusWL]

Besides the merge conflict, this LGTM 👍

[github-advanced-security]

Found 2 vulnerabilities.

[RasmusWL]

this bit is not going to work after the merge 😳 my approval was just a second too fast 😂