Question about safe/unsafe HTTP methods treating

[veldic]

When we were working on our backend code, we created(actually copy & paste of hw4 skeleton code) token providing function.

@ensure_csrf_cookie
def token(request):
    if request.method == 'GET':
        return HttpResponse(status=204)
    else:
        return HttpResponseNotAllowed(['GET'])

But SonarCloud says

• An HTTP method is safe when used to perform a read-only operation, such as retrieving information. In contrast, an unsafe HTTP method is used to change the state of an application, for instance to update a user’s profile on a web application.

• Common safe HTTP methods are GET, HEAD, or OPTIONS.

• Common unsafe HTTP methods are POST, PUT and DELETE.

• Allowing both safe and unsafe HTTP methods to perform a specific operation on a web application could impact its security, for example CSRF protections are most of the time only protecting operations performed by unsafe HTTP methods.

to us with Quality Gate Failed.

I think we can solve this warning by adding @require_GET annotation to this function (SonarCloud recommended us to do so). But I don't have any idea how to deal with the function that will use safe('GET') and unsafe('POST', 'DELETE', ...) methods together.

Is there any proper way to treat this warning?

[kdh0102]

Sorry for the belated response. The proper way to handle the warnings is to follow the coding practices suggested in the recommendation tab, which you already have seen. the function with both safe('GET') and unsafe('POST', 'DELETE', ...) methods itself violates the warning: Allowing both safe and unsafe HTTP methods is security-sensitive.

[clarkindy]

@kdh0102, I do not think the answer solves the original question:

But I don't have any idea how to deal with the function that will use safe('GET') and unsafe('POST', 'DELETE', ...) methods together.

Our team has the same problem, and I think other teams are having the same issue too.

We want our back-end application to handle requests to a URL differently based on what HTTP method was used. For example, HW4 specifies us to do so:

• GET /api/article/: Response with a JSON having a list of dictionaries for each article's title, content, and author. The value of the author must be the id of the author but not her username. You don't need to include the id of each article to the response.
• POST /api/article/: Create an article with the information given by request JSON body and response with 201. Posted article (with it's assigned id) should be included in response's content as JSON format.

Therefore, we have to allow multiple methods in one view function. We can see this in the code of our Django practice session repository:

@csrf_exempt
def hero_list(request):
    if request.method == "GET":
        ...
    elif request.method == "POST":
        ...
    else: 
        return HttpResponseNotAllowed(["GET", "POST"])

The problem is, as you mentioned, SonarCloud does not allow a view function to accept both safe and unsafe methods. I think this could be a problem if the view function does the same thing regardless of which HTTP method was used. This is not our case, since we strictly divide our function's behavior with if-else statements. However, SonarCloud does not seem to care about our view function's internal structure, and only cares about whether the function accepts both safe and unsafe methods.

There are potential solutions:

• SonarCloud suggests that we use @require_GET, @require_POST, @require_safe, or @require_http_methods(). However, they can be used only when the view function handles only safe methods or only unsafe methods.
• We might be able to write separate view functions handling different HTTP methods. However, we have to use separate URLs for each view function. In my humble opinion, that leads to unnecessarily complex URLs and is against what we learned.
• The only way I found to not trigger SonarCloud (which does not involve using separate URLs) is to use class-based views, which we did not cover in our class.

So I want to ask whether there is any way to handle this issue only using what we learned in our class.

[kdh0102]

@clarkindy Thanks for sharing your experiences and opinions.

• First of all, our class materials are not guaranteed to satisfy all the python static code analysis rules, and there is no clear way to handle the security hotspot only with the class materials.
• Secondly, all the suggestions you noted are valid solutions. Regarding the second solution, as you noted, the urls can be complex if you separate all the view functions, but the code complexity is a different aspect to the security. If you do not have many functions with both GET and POST methods, the second method is also a good way. In addition, It would be great if you share the third solution to other students.
• In addition, the detected security hotspots do not mean your project is insecure. The hotspots tell you to review whether to apply the fix. It is your decision how to handle the issues. Note that this case (using GET and POST methods in one function) is not something prohibited. You can easily find out cases with both GET and POST methods (e.g. OpenID UserInfo).

[clarkindy]

Thank you for your answer.

The hotspots tell you to review whether to apply the fix. It is your decision how to handle the issues.

Is there any way to pass quality gate without handling security hotspots?

By the way, class-based views are a way to generate views by making sub-classes of django.views.View. You can find more information in Django documentation.

[kdh0102]

You can manually review each hotspot in the SonarCloud page.

[clarkindy]

Oh, I did not know that. Thank you!