Jacques1

You've missed the point. It's generally somewhat pointless to talk about details like this when you're not familiar with basics like objects, attributes and methods. There are many introductions for object-oriented PHP. You should start there. The first page I came accross is this one.

Hi, it's really simple: $this refers to the current object, and self refers to the current class. The -> operator is used to call a method or access an attribute of an object. And :: is used to access a static method or attribute of a class. <?php class A { public static $stat = 'Some static attribute'; public $inst = 'Some attribute of the instance'; public function test() { var_dump(self::$stat); // self refers to the class A var_dump($this->inst); // $this refers to the specific instance of A } } $a = new A(); $a->test(); There are some gotchas as to how self behaves in subclasses, but you should get the basic idea.

Passing uncontrolled input to a shell isn't a good idea on any planet. I wouldn't be surprised if the issue with the dollar signs is a symptom of this severe bug. If you think you should keep the script, I can't stop you from doing that. Unfortunately, there are no laws against terrible code. But if you care just a tiny, tiny bit about things like quality or correctness, flush this sh*t down the toilet.

$cmd="$shellscript " . $_POST['username'] . " " . $_POST['passwd']; ... exec($cmd,$output,$status); Seriously, WTF? Do you understand that this piece of code gives any website visitor direct access to a system shell? This script is malware. It's a backdoor. You need to delete it right now. You can't just download some PHP code you found on some fishy website. Do you not understand how dangerous this is? I mean, you wouldn't download an executable file from an untrusted source, would you? If you don't know PHP, then either learn it or don't use it. But downloading random PHP code from the Internet is definitely not an option.

Oh man. Your code is wide open to SQL injections. Has it never occured to you that stuffing raw user input into an SQL query string might be a bit ... problematic? It's even sadder given the great security features of MySQLi. You need to start thinking about security. And then it might be a good idea to learn how to use MySQLi.

This obviously makes no sense. How do you expect PHP to change the error settings at runtime when it can't even parse the code? You need to configure your error reporting before the script runs. The manual tells you how: http://php.net/manual/en/configuration.changes.php

No, you didn't fix the vulnerability. And I don't think you understand the problem. Try calling your script with this URL: localhost/yourscript.php/%3Cscript%3Ealert(%27XSS%27)%3C/script%3E This is a perfectly valid URL. But if you open your page with it, you'll see a JavaScript popup saying "XSS". Oops. Your sanitzing stuff doesn't do anything. The problem is that you fail to escape the URL and allow the user to inject malicious JavaScript code into your page. That's what needs to be fixed. Whether or not the URL is valid is completely irrelevant for this. So you need to escape the URL like any other user input: <?php // if you don't use UTF-8, adjust the encoding function html_escape($raw_input) { return htmlspecialchars($raw_input, ENT_QUOTES, 'UTF-8'); }

Or simply while ($row = sqlsrv_fetch_array($results, SQLSRV_FETCH_ASSOC)) $roster[] = $row; echo json_encode($roster);

I'm talking about the braces right after the $roster[] = $row. They don't do anything, because they're not attached to any control structure. Remove them.

What are those weird braces after the $roster[] = $row supposed to do?

The reason why you get each array encoded individually is because that's exactly what you've told PHP to do: You have a loop, and in this loop, you encode and echo each $row. If you want to collect all rows in an array and then encode the whole thing, well, do that.

This is a massive security hole, because the “e” modifier can be used by visitors to run arbitrary PHP code. Please read the warnings in the manual: http://php.net/manual/en/reference.pcre.pattern.modifiers.php#reference.pcre.pattern.modifiers.eval In general, I strongly recommend you keep away from any home-made BBCode implementation. Almost every attempt I've seen so far ended up with all kinds of cross-site scripting vulnerabilities or worse. Use an established library. What about this one?

Hi, first of all, running around with PHP 5.1 is suicidal. This version was abandoned back in 2006(!) and didn't receive any updates since then. If your hoster installed it for you, they're not doing their job. Secondly, they gave you a wrong certificate. This one is only valid for secure39.prositehosting.co.uk, which probably isn't very helpful for you. It is good practice to encrypt all pages. Don't let some moron tell you otherwise. If you only do partial encryption, this is the perfect opportunity for an attacker to jump in and prevent the user from ever establishing an encrypted connection. TLS (or “SSL” as you call it) really only makes sense if there are no loopholes. Don't base your decisions on “I've heard somebody say something”. If you're worried about performance issues, you need to actually measure the performance. If it's fine, there is no problem. Otherwise, there are many different ways to optimize TLS.

How could we possibly help you when you don't post any code?

I gave you two links with two short explanations of all relevant basics. Now it's up to you: You can waste the next days, months, years copypasting crap code from dubious websites and asking other people to fix it for you. Or you can start to read the explanations and actually learn PHP. Writing proper code is no rocket science. I think everybody with basic intelligence can do it. However, if you want to learn a language, you do need to read. You can't just copypaste other people's stuff. This may get you quick results, but you're not gonna learn anything from it.

Remember when you promised to escape all user input? Now you're again happily stuffing raw input into query strings. Do you not understand how dangerous this is? It allows anybody to manipulate the queries in any way they want. This can be used to steal all data or even compromise the entire server. Yes, people do that, and it's not even difficult. You need to start thinking about security. The Internet is a hostile environment with a lot of criminals and script kiddies who would love to take over your server. While you're at it, get rid of this stupid mysql_* stuff. It's obsolete since more than 10 years and will be removed in the near future. We use PDO and MySQLi now.

Looks like you've indeed missed the last 13 years.

Um, I think you're missing the point. This spam stuff may be annoying, but the real problem is that somebody somehow managed to gain access to your server. And maybe they still have. So the first step is to find out what exactly happened (are the logs still intact?). Then get rid of FTP and replace it with a secure protocol like SCP or SFTP. Really, sending unencrypted traffic around the Internet is reckless. Also make sure you have a very strong password. Even better, get rid of the password as well and use public-key authentication. Then worry about the links.

1: RTFM! We're not gonna read it to you. 2: There is no magical “sign in” parameter. The API provider has to tell you how they expect you to send the credentials.

Wrong, wrong, wrong. It hate being the party pooper, but input validation has absolutely nothing to do with security. When you think it does, you're committing two fallacies at the same time: You mistake injection vulnerabilities for input problems. They're not. You try to apply a “one-size-fits-all” approach, which never ends well. Things like SQL injections or cross-site scripting are not an input problem. They're not caused by the user giving you “wrong input”. Let me try something: DROP TABLE phpfreaks.users; Did I just kill PHP Freaks? No. This “dangerous query” does absolutely nothing. It's a harmless piece of text in a forum. However, it would cause trouble if the application actually executed this query. So SQL injections are in fact an interpretation problem. They happen when the application misinterprets data as executable code and runs it. This is really important to understand: Injections vulnerabilities are not an input problem. You cannot prevent them through validation, filtering or whatever, no matter how hard you try. You need to make sure that the data actually gets interpreted as data and never as code. This is usually done through escaping. Secondly, abusing validation as a security feature is a “one-size-fits-all” attempt. Sure, a number probably doesn't do any harm in any context. But what about, say, an e-mail address? Is that dangerous? In some contexts, yes! E-mail addresses are allowed to contain single quotes, so they may very well be used for an SQL injection. As I already said above, preparing data is always context-dependent. You can't just run them through some validator and be happy. This doesn't work. You have to prepare the data for the specific context. If you want to include it in an SQL query, you need a prepared statement or SQL-escaping. If you want to include them in an HTML document, you need HTML-escaping. And if you want to put them into a JavaScript context, you need yet another strategy. I know, this is a bit more complicated than calling some silly number validator. But this is reality. Nobody said programming is easy.

A URL parameter itself is just a piece of data coming from the client. It isn't any more dangerous than a form entry or a cookie or whatever. Trouble begins when programmers fail to process the data properly. For example, if you insert the raw value into an SQL query, attackers can use this to manipulate the query. And if you insert the value directly into your HTML document, this can be used to inject malicious JavaScript code. It's very important to understand that this is not a problem of the data itself or how the data is passed to your server. The client may send any data they want in any way they want. It's your responsibility to make sure your application doesn't do funky stuff with it. Proper handling of data always depends on the specific context. There is no “one-size-fits-all” solution. Preparing data for an SQL query is an entirely different thing than preparing it for an HTML context. If you want us to help you, you need to show us the exact context. Do you want to use the parameter in a query? The HTML document? Somewhere else? For a start, you might wanna read this introduction.

Hi, you're talking in riddles. What's “a switch in the URL”? You mean the x parameter? How is that a security risk?

No. A session consists of three different things: a session file on the server, the $_SESSION array in the current PHP process, and a session cookie in the user's browser. To properly terminate a session, you need to clear all three things. The PHP manual explains exactly how to do that.

Again: Escape and quote your attributes! If you keep forgetting this, write it down on a post-it and stick it to your screen. This is really, really important. Besides that, the textarea element has no value attribute. The (escaped!) content goes between the tags.

Abusing regexes to write a wacky HTML parser is crap. Where's the closing tag? That site has no flag for making "." match newlines. At least it's not documented.