[C#] The System.Web.UI.Page Server.ScriptTimeout property should not be set via code

Rules and Languages New rules / language support
1

Setting the ScriptTimeout on a (web) page is potentially dangerous: it changes the behavior of the website, on every request, and bypasses a globally configured value (web.config).

public class SomePage : System.Web.UI.Page
{
    public int Other { get; set; }

    public System.Web.HttpServerUtility XServer { get { return Server; } }

    public void OnLoad()
    {
        System.Console.WriteLine(Server.ScriptTimeout); // Compliant, just reading the value.
        this.Server.ScriptTimeout = 1; // Noncompliant
        Server.ScriptTimeout = 2; // Noncompliant
        XServer.ScriptTimeout = 3; // Noncompliant
        Other = 4;
    }
}
public class SomeSecurePage : SomePage
{
    public int Other { get; set; }

    public void OnLoad()
    {
        System.Console.WriteLine(Server.ScriptTimeout);// Compliant, just reading the value.
        Server.ScriptTimeout = 6; // Noncompliant
        Other = 7;
    }
}

public class NoPage
{
    public System.Web.HttpServerUtility Server { get; set; }

    public void OnLoad()
    {
        Server.ScriptTimeout = 8 + 14; // Noncompliant
        Server.ScriptTimeout += 9; // Noncompliant
        Server.ScriptTimeout = Get10(); // Noncompliant
        Server.ScriptTimeout -= 11; // Noncompliant
        Server.ScriptTimeout *= 12; // Noncompliant
        Server.ScriptTimeout /= 13; // Noncompliant
        Server.ScriptTimeout >>= 15; // Noncompliant
        Server.ScriptTimeout <<= 16; // Noncompliant
        var x = Server; // Noncompliant
        x.ScriptTimeout = 7; // Noncompliant
    }

    private int Get10() { return 10; }
}

Public Class SomePage
    Inherits System.Web.UI.Page

    Public Property Other As Integer

    Public ReadOnly Property XServer As System.Web.HttpServerUtility
        Get
            Return Server
        End Get
    End Property

    Public Sub OnLoad()
        System.Console.WriteLine(Server.ScriptTimeout) ' Compliant
        Me.Server.ScriptTimeout = 1 ' Noncompliant
        Server.ScriptTimeout = 2 ' Noncompliant
        XServer.ScriptTimeout = 3 ' Noncompliant
        Other = 4
        With Server
            .ScriptTimeout = 5 ' Noncompliant
        End With
    End Sub
End Class

Public Class SomeSecurePage
    Inherits SomePage

    Public Property Other As Integer

    Public Sub OnLoad()
        System.Console.WriteLine(Server.ScriptTimeout)  ' Compliant
        Server.ScriptTimeout = 6 ' Noncompliant
        Other = 7
    End Sub
End Class

Public Class NoPage

    Public Property Server As System.Web.HttpServerUtility

    Public Sub OnLoad()
        Server.ScriptTimeout = 8 + 14 ' Noncompliant
        Server.ScriptTimeout += 9 ' Noncompliant
        Server.ScriptTimeout = Get10() ' Noncompliant
        Server.ScriptTimeout -= 11 ' Noncompliant
        Server.ScriptTimeout *= 12 ' Noncompliant
        Server.ScriptTimeout /= 13 ' Noncompliant
        Server.ScriptTimeout \= 14 ' Noncompliant
        Server.ScriptTimeout >>= 15 ' Noncompliant
        Server.ScriptTimeout <<= 16 ' Noncompliant
        Server.ScriptTimeout ^= 17 ' Noncompliant
        Dim x As System.Web.HttpServerUtility = Server
        x.ScriptTimeout = 18 ' Noncompliant
    End Sub

    Private Function Get10() As Integer
        Return 10
    End Function

End Class
2

Hello @Corniel

Welcome to the community and thank you for this suggestion!

Bypassing a globally configured value is a very common practice in all languages thus not a strong evidence to raise an issue. So let’s talk about the impact of this local setting:

1/ if a developer increases the scripttimeout value on a specific page it’s because he knows that his script could have a long execution time on this page, we can think it may lead to potential denial of service attacks but:

  • the root cause is not scripttimeout setting but likely some pieces of code (like database queries) that need significant execution time to complete, even if scripttimeout prevents a script to run too long, it is not really a protection against an attacker who can simply re-request the webpage when the script is ended (when scripttimeout value is reached).
  • if “we force” the developer to remove these Server.ScriptTimeout calls with a pressing/security rule the script could end before “the tasks/calculations” on this page are completed, it could break the behavior/logic of the script to me.

2/ I would say raising a “code smell” type of issue (@Nicolas_Harraudeau) is maybe more appropriate when Server.ScriptTimeout is set to a high value with this kind of message: " it appears you expect the script to have a long run time, have you made all the changes possible to optimize it? "

Eric

3

The root IS ScriptTimeOut. Actually this piece of code is running in a company I used to work for, due to the risk.

The point is, that if you change it at one page, it will keep that value for every page untill you have an AppDomain refresh (reboot).