darkfreaks

as i mentioned it is preffered to use PDO instead of mysql_real_escape_string as my scanner pinged your site out it is trying to access the site like so file http://dev.vorak.com/1/'" was not found then below this is where the syntax error is. While mysql_real_escape_string is efficient there is some charsets and characters it does not escape.

correct you are. i was merely stating that PDO is preffered over mysql_real_escape_string. so if your not using either of those are you at least using mysqli ??? otherwise you are prone to injection in some form.

thanks for fixing it it also fixed up a minor google hacking thing as well about page error. i think it had more to do with your redirect not terminating. also does your script use PDO over mysql_real_escape_string it does clean up more nicely than the later IMO.

well your script IP ban my scanner so there is no way currently i can manually check either. anyhow HTML Form found in redirect page Vulnerability description Manual confirmation is required for this alert. An HTML form was found in the response body of this page. However, the current page redirects the visitor to another page by returning an HTTP status code of 301/302. Therefore, all browser users will not see the contents of this page and will not be able to interact with the HTML form. Sometimes programmers don't properly terminate the script after redirecting the user to another page. For example: <?php if (!isset($_SESSION["authenticated"])) { header("Location: auth.php"); } ?> <title>Administration page</title> <form action="/admin/action" method="post"> <!-- ... form inputs ... --> </form> <!-- ... the rest of the administration page ... --> This script is incorrect because the script is not terminated after the "header("Location: auth.php");" line. An attacker can access the content the administration page by using an HTTP client that doesn't follow redirection (like HTTP Editor). This creates an authentication bypass vulnerability. The correct code would be <?php if (!isset($_SESSION[auth])) { header("Location: auth.php"); exit(); } ?> <title>Administration page</title> <form action="/admin/action" method="post"> <!-- ... form inputs ... --> </form> <!-- ... the rest of the administration page ... --> Affected items /pages/inbox.php The impact of this vulnerability The impact of this vulnerability depends on the affected web application. How to fix this vulnerability Make sure the script is terminated after redirecting the user to another page.

can you post the code for your index(main) page so i can see where you are going wrong? and why it errors everytime the value 1 is inserted.

also try making sure field|columns|tables are not MYSQL Reserved Words if they are they need to be enclosed with `backticks` and not 'single quotes' .

if i were you i would run my SQL statements through a syntax checker like MIME SQL or Yacker SQL. they usually tell you where your SQL has gone wrong syntax wise. i am pretty sure it is on your index.php page. since i know it is not login or register pages.

i believe it would better suit yourself to buy some more PHP/javascipt/ajax books and read them up and practice what they teach. then make your own login system, instead of piecing code together or using already provided code.

click the link(s) in my signature it should help you more than getting started in learning PHP

not really sure what page it was but it had the link to the login and register page right above where the error was.

Trust me my head also wants to explode also. On here http://forums.phpfreaks.com/index.php?topic=37442.0 it says "All of this can be avoided if you make sure that your favorite editor saves your documents without the byte order mark or, alternatively, by enabling output buffering in php.ini." Yet on the forum when I ask if I should do this I'm told "nope". Thats its just "nope". Why does the sticky guide say I should enable output buffering in php.ini yet on the forum I'm told "nope". NEW EDIT TO THIS TOPIC: what usually results in these errors is poor script design. when one processes a form, they should do it BEFORE OUTPUTTING ANYTHING TO THE BROWSER. there is NO reason that the process cannot be operated in the header of the document, before any HTML is output. let's take a common example. the programmer wants a login form which checks the username and password against the database. if they don't match, then don't set a cookie remembering them and tell them it failed. if they do match, set the cookie and send them to a member page. many will do: [php processing the form] [form code] because they can simply echo any errors straight from PHP right above that form. they can also send a success message, set the cookie, and header() them off on their merry way without seeing the form again. it's a logical place to put this code. think again. you'll (perhaps not so) obviously get header errors when you go to use setcookie() and header(). if the login fails, it's dandy, but if you have a successful login the user gets nowhere. answer: put the processing in the header, and store the results in variables. perhaps a $result variable that is 1 if successful, 0 if failed. then $output that contains either a success message or customized error messages. the new code would look like: [php processing the form (if it was sent) and storing the results] [html starting the page and layout] [php echoing the results] [form code if failed - exit(); if successful]

so i was trying to figure out why it was picking up SQL injection on your site so i launched it visually and in your page i see this..... You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '2000'' at line 1

@ OP: Reducing site spam

my head just wants to explode reading 4 pages of sheer ignorance from the OP.

marked this as solved if they have both been patched already.

http://www.dotdeb.org/2012/05/09/security-php-5-4-3-and-php-5-3-13/ something it also picked up on and by reading that i do believe it is possible at least upgrading the PHP version. to fix in debian 6 squeeze.

so was it unpatched or should i mark it as a false positive

Ciphers have been fixed CVE-2011-3192 hope this helps.

@Pickachu: oops my bad i see why you posted that : anyhow updated to latest version of Acunetix. it is telling me you are running Apache 2.2.16 which as of 2011 has several security flaws in it. if you are not using this version no worries. however if in the event you are might want to upgrade to a newer version => 2.2.19 Dowload Apache

@ pikachu 1. Acunetix Also i am aware scanners give bogus results i was not aware that it was a false positive until i manually checked. also i am aware that no action will be taken against me as long as i post the reason that the code is at risk and why it is.

SSL weak ciphers Vulnerability description The remote host supports the use of SSL ciphers that offer either weak encryption or no encryption at all. This vulnerability affects Server. Discovered by: Scripting (ssl_ping.script). The impact of this vulnerability Attack details Weak SSL ciphers (SSL3 on port 443): SSL3_CK_RSA_RC4_40_MD5 - Low strength SSL3_CK_RSA_RC2_40_MD5 - Low strength SSL3_CK_RSA_DES_40_CBC_SHA - Low strength SSL3_CK_RSA_DES_64_CBC_SHA - Low strength SSL3_CK_EDH_RSA_DES_40_CBC_SHA - Low strength SSL3_CK_EDH_RSA_DES_64_CBC_SHA - Low strength also the XSS is a false positive i have looked it up. but you might want to update your SSL Ciphers. will look for an updated version of this scanner

technically i don't have to do anything when the .txt file no lionger exists and neither does the demo site.

@OP: i would assume you have unfiltered $_GET data being passed into the function. //unfiltered get input $input = $_GET['input']; sanitized input: //strip tags from input occasionally encode special chars $input = filter_input(INPUT_GET,'input',FILTER_SANITIZE_STRING);

@ OP your best bet would be using the multidimensional array function for BBcode i provided it DOES NOT use strip_tags or htmlentities

http://goo.gl/robots.txt you still have /info/ in your robots.txt please remove it if it does not link to the site.