rupertrealbear
-
Posts
6 -
Joined
-
Last visited
Never
rupertrealbear's Achievements
Newbie (1/5)
0
Reputation
-
os Linux Kernel version 2.6.18-53.el5.028stab051.1 WebHostManager version 11.15.0 cPanel version 11.18.6 Apache 1.3.41 MySQL version 4.1.22 PHP version 5.2.5 Hi I wanted to see LOCK TABLES actually preventing another user from reading or writing to a table in my VPS (account name "charlie"). The following test seemed not to lock anything (the second user was always able to read and write to teh test table):- I created a table in a database charlie_gs, inserting one record CREATE DATABASE `gs`; CREATE TABLE `testlock` (`stuff` varchar(50) NOT NULL default ''); INSERT INTO `charlie_gs`.`testlock` (`stuff`) VALUES ('anything'); I created a user tstlk_can with LOCK TABLES priviledge on the database charlie_gs and UPDATE and SELECT priviledges on the new table testlock; I then created a user tstlk_can with only UPDATE and SELECT priviledges on the new table testlock GRANT USAGE ON * . * TO 'tstlk_can'@'localhost' WITH MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 ; GRANT LOCK TABLES ON `charlie\_gs` . * TO 'tstlk_can'@'localhost'; GRANT SELECT, UPDATE ON `charlie_gs`.`testlock` TO 'tstlk_can'@'localhost'; GRANT USAGE ON * . * TO 'tstlk_cant'@'localhost' WITH MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 ; GRANT SELECT, UPDATE ON `charlie_gs`.`testlock` TO 'tstlk_cant'@'localhost'; FLUSH PRIVILEGES ; My guess was that by creating two distinct connections (in a session controlled by PHP script), user tstlk_can could invoke LOCK TABLES and prevent user tstlk_cant from reading or writing table testlock as the following <?php header("Cache-Control: no-cache"); $link1 = mysql_connect("localhost","tstlk_can","",true); mysql_select_db("charlie_gs",$link1); $changeSQL = "UPDATE testlock SET stuff = 'Lock SUCCESSFUL: stuff as originally changed by tstlk_can'"; mysql_query($changeSQL,$link1); $lockSQL = "LOCK TABLES testlock AS tstlkRDLK READ, testlock AS tstlkWRLK"; mysql_query($lockSQL); $link2 = mysql_connect("localhost","tstlk_cant","",true); mysql_select_db("charlie_gs",$link2); #when un-commented, the following should unlock the tables implicitly #mysql_close($link1); $changeSQL = "UPDATE testlock SET stuff = 'Lock UNSUCCESSFUL: stuff changed by tstlk_cant'"; mysql_query($changeSQL,$link2); $affected = mysql_affected_rows($link2); $str = $changeSQL."<br>No of rows affected by UPDATE: ".strval($affected)."<br>"; $rs = mysql_query("SELECT stuff FROM testlock"); if ($rs) { $row = mysql_fetch_row($rs); $str .= $row[0]; } else $str .= "tstlk_cant could not SELECT on testlock"; ?> <HTML> <HEAD> <TITLE>testlock</TITLE> </HEAD> <BODY> <h1><?php echo $str; ?> </h1> </BODY> </HTML> I wondered if there might be some silent disabling when privileges are set in PHPMyAdmin rather than through cPanel? Hope someone can sehd light (I have probably assumed something wrong!) Regards rupertrealbear
-
I have since found that the call to mysql is closed automatically so there is no need to "QUIT"
-
Hi I managed to alter something in my MySQL database (on a VPS) by creating a user "cron" with no priviledges and then granting it a few table-specific priviledges in the database in question. A small text file was created containing some MySQL statements: mysql -h localhost -u cron < quick.txt quick.txt just connected to the databse and updated the test field in a table called sample:- USE crontest; UPDATE sample SET test = "changes successful"; My plan is to use a cron job to perform some useful databse housekeeping one every minute. I notice that you are advised to use the "QUIT" command (if calling mysql in batch while logged in on the local machine). Would adding "QUIT;" at the end of quick.txt achieve that end?
-
Hi I set up some directives to require a password on a particular folder off my document root /public-html/hq in an .htaccess in that folder:- AuthName "Restricted Area" AuthType Basic AuthUserFile /home/charlie/.htpasswd AuthGroupFile /dev/null require valid-user . . . which worked ok with a .htpasswd in my server account root. I also needed to force ALL requests to my site to be changed on htpps:// requests, for which I had successfully added these directives to a .htaccess in my /public-html folder:- . . . RewriteEngine On RewriteCond %{HTTPS} off RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} When both these directives are in effect, I find that requests to a script in /public-html/hq generally gets redirected to a non-existent error document /401.shtml and the visitor is left with a "File not Found". I moved the 'force SSL' directives into the .htaccess in /public-html/hq:- RewriteEngine On RewriteCond %{HTTPS} off RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} AuthName "Restricted Area" AuthType Basic AuthUserFile /home/charlie/.htpasswd AuthGroupFile /dev/null require valid-user . . . which gets me in but asks or the password TWICE (before and after changnig the request into a https:// one). I suppose I could bare subjecting the user to having to enter their password again - but isn't there some subtle workaround ? Any suggestions much appreciated Rupertrealbear
-
SSL on a VPS: is my code safe?
rupertrealbear replied to rupertrealbear's topic in Application Design
Not surprisingly, this post has not been replied to, since I had failed to notice a tutorial - on the freaks home page! - posted 30th June 08: "PHP Security" by Daniel Egeberg. Other stuff I found on my own are a good wikipedia on file permissions and Linux File Permission Confusion by Brian Hatch on his "Hacking Linux Exposed" website -
Hi I have started renting a VPS and installed an SSL certificate (ironing out secure (https://) cPanel login, just now) and I have an account hosting PHP scripts that serve dynamic WML to mobile phones - which are using interactive WAP pages to function as remote data capture devices. The target for data exchange is an Access database behind a firewall. Data exchange through the firewall is via named testboxes in an HTML form posting to itself (triggered by Access). The data is somewhat encoded in textual "bytes" base 60 or 70 or even plain text in some cases: I am assuming that the https:// URL encrypts the transmitted form data. The above appears to be a good start at a securing my sight (I don't think there is danger of XSS, for instance: data is only stored in the firewalled database - other data is not stored directly in tables on the VPS, except in buffer form - waiting to be posted; they will be encrypted and decrypted for that purpose). I am relying on the PHP scripts not being readable and I am sure there is more I need to do. Can someone give me a few pointers? Rupertrealbear