Come si sono evolute le iniezioni SQL? (Domanda specifica + Discussione aperta) [chiusa]

First time posting on Security Stack but I have benefited a lot from previous posts. I am currently a security cyber security grad student and I am building up my thesis project right now: it is effectively another vulnerable web application suite (like DVWA or WebGoat) but focuses heavily on teaching the back-end of these attacks and providing more hands-on examples--along with hopefully updated and more relevant kinds of attacks based on things like the OWASP top 10 for 2017.

For the sake of time and my thesis I am just going to build section covering injection attacks (as it seems like that is some of the most common and devastating kinds of web-based attacks). The rest will come on my own time. Anyway, here is my question:

Sembra che siamo in un cambiamento su quanto siamo effettivamente vulnerabili. In questo momento sto costruendo la mia applicazione in PHP e MySQL, e sembra che il passaggio a MySQLi abbia davvero risolto molto delle iniezioni SQL basate sull'aggiunta. Significa che le iniezioni come:

mysqli_query("SELECT email, passwd, login_id, full_name FROM members WHERE email = 'x'; DROP TABLE members; --'");

in realtà non funziona, dato che il mysqli_query () aggiornato consente di passare una sola istruzione SQL single in qualsiasi momento, e se ne viene tentata un'altra, la funzione restituisce false. Gli sviluppatori dovrebbero in particolare utilizzare il tipo mysqli_multi_query () affinché ciò accada, e ciò non sembra probabile per i moduli di accesso semplici.

Quindi adesso ho una semplice applicazione che visualizzerà una riga della tabella basata sull'utente che fornisce un nome utente e una password corretti:

<?php
    // Prevent errors from showing
    error_reporting(0);
    // Connect the db
    require '../../connect_db.php';

    if (isset($_POST['UserName'], $_POST['UserPass'] ) ) {

        // Grab user Input
        $UserName = $_POST['UserName'];
        $UserPass = $_POST['UserPass'];

        // The passwords in this case are stored in the clear. This is an early example. 
        // BINARY is used to force matching case. 
        $query = "SELECT * FROM users WHERE UserName='".$UserName."' AND BINARY UserPass='".$UserPass."'";

        $result = mysqli_query($db, $query)
         or die("Error: " . mysqli_error($db));


        // Echo out the table row(s)
        while($row = mysqli_fetch_array($result)) {
            echo '<tr class="query-result">'; // Class is added so that jQuery can remove old ones
            echo '<td>' . $row['UserId'] . '</td>';
            echo '<td>' . $row['UserName'] . '</td>';
            echo '<td>' . $row['UserPass'] . '</td>';
            echo '<td>' . $row['UserRole'] . '</td>';
            echo '</tr>';
        }
    }

So che, come scritto che questo attacco è vulnerabile all'iniezione "OR"="- ma per il codice di cui sopra, quali altri tipi di attacchi di iniezione potrebbero accadere? Sembra davvero che gli attacchi per iniezione più conosciuti si siano realmente basati sulla capacità di UNION o in qualche modo di impilare comandi SQL - supponendo che gli sviluppatori stiano utilizzando la sintassi MySQLi aggiornata, quali altri tipi di attacchi per iniezione valgono la pena di prepararsi? E possiamo effettivamente non preoccuparci degli attacchi per iniezione "a base di stack"?

Mi piacerebbe qualsiasi e tutte le risorse che potresti gettare su di me, poiché spero di poterlo condividere con la più grande comunità di sicurezza.