jazzman1

we actually need to see what data the client (your browser) sends to the server. Add var_dump() on top of the delete.php file: var_dump($_GET);

Are you still using NetBeans? There is a format function formatting code to be more readable. The short command is Alt+Shift+F. The following doesn't look nice and it's not into a human readable format. Remember, we are not machines while ($row = mysqli_fetch_assoc($result) ){ .......

Try, $query = "insert into points values ('{$v[0]}',{$v[1]},'$At') on duplicate key update Points = Points + $v[1]"; $r = mysql_query($query) or die(mysql_error());

I am sorry for any misunderstanding. This testing brute-force was against my account located in my local server that's why the speed of the attack was very high. In the reality it's slightly different So, make sure you have a strong password and algorithm for it.

Absolutely! Using prepared statements will guarantee, that even though they could be executed multiple times (as in your steps example) they are compiled and optimized only once by the database engine. We should always be using prepared statements in our application.

I didn't say nothing against of using the bcrypt algorithm. I just didn't understand what OP meant by saying that? Jacques, I find you pretty freaky and very sensitive when speaking for security....just relax ... mate...relax Yeah....agreed...he is very good.

@David, what did you mean by saying "improving performance on queries run in a loop"? Prepared and executed statements have nothing to do with application languages such as php, for instance. All prepared and executed statements occurred in database server, what PDO did is just collecting them, so they can be thought like a sql template with collection of sqls. But, if you meant by saying this on a database level, yes, you are correct. For example, prior firebird 2.5 version, the execute statement occurred in a loop was prepared, executed and released upon every iteration, which wasn't good. Anyways.... like the mac_gyver's post #3 especially the first paragraph

To brute-force by hash? What do you mean? Using a hashing password would not prevent you from brute-forcing. Below is an example of brute-forcing over an html-form-based authentication to my account using php password_hash and bcrypt algorithm. More information and examples about the brute-force attack can be found here - https://www.owasp.org/index.php/Testing_for_Brute_Force_%28OWASP-AT-004%29

Add a semicolon at the end - $row = mysqli_fetch_assoc($result)

You could do this using a sql case operator to take all possibilities, or use php to build this query. What have you done so far?

A common, standard sql way of doing this is: UPDATE tbl_one t1 SET t1.email = (SELECT t2.email FROM tbl_two t2 WHERE t1.id = t2.cID) WHERE EXISTS (SELECT 1 FROM tbl_two t2 WHERE t1.id = t2.cID) PS - Don't forget to backup your data before trying this ( for every case)

Most likely the port is blocked. What port are you using to get that data? 80? Do nmap -PN ip_server_2 and post out the result.

Why not. If the attached data is a part of the mail's content you could use regex to grep only those files.

You need to set the second parameter of md5() hash function to false rather than true (or you could omit it entirely). For more information checkout the manual of the function. $pass = md5($_POST['password'].$salt,true); // must be $pass = md5($_POST['password'].$salt,false); // or $pass = md5($_POST['password'].$salt); Your update statement is now correct.

Psycho, have you read the bugs message from authors of this program?

And the question is why? This is a horrible and sadistic thing against you computer and all services on it

Yeah, got it. You are right. Each data value is escaped properly before the query to be built

A chance to see some part of your actual code?

@Ch0cu3r, a little correction if you'll allow me Don't forget that php implode function join array elements with a string values, so all values in the example are actually strings with not escaped values. You need to use mysqli_real_escape_string and the others function after the values to be imploded not before.

Then check if $_GET or $_GET['name'] is set to the url and add the value of this variable to the log file.

I am getting so sensitive seeing somebody to use a directory path(s) something like yours "../../../" You should really avoid them, instead use an absolute one. PS: Do all values you want to insert to database are strings?

add the session_start() on top of the second page, telling php that a session is used, also turn php error on. <?php ini_set('display_startup_errors', 1); ini_set('display_errors', 1); error_reporting(-1); session_start(); include_once "../../../test/include/db/db.inc.php"; // rest of your script

Can I see the output from var_dump, just to be sure

Change those two lines: $salt = md5(uniqid(rand(), true)); $pass = md5($_POST['pass'].$salt,true); // to $salt = md5(uniqid(rand(), true),false); $pass = md5($_POST['pass'].$salt,false); I don't understand these variables too: $password = mysqli_real_escape_string($con, md5( $_POST['pass'])); $password_again = mysqli_real_escape_string($con, md5( $_POST['pass_again'])); Just comment them out for now. This database table structure should be normalized! But this is a different story

Hm...tell me the truth, what you don't understand in my example #26? You're not hashing and salting the user pass at all, that's why you get a false result every time.