Looking for exploits on my server.

[Spork Schivago]

Re: Looking for exploits on my server.

The problem is fixed. suphp was blocking access to index.php because it was group writable. When I renamed it to index.html, it must of somehow changed the permissions. I was root when I did it.

[Spork Schivago]

Re: Looking for exploits on my server.

I've even removed the .htaccess, thinking that would stop it from happening, but nope. So long as there's an index.php page, the site has a redirect loop. If, in the .htaccess file, I replace

RewriteRule ^(.*) https://%{HTTP_HOST}/$1 [R]

with

RewriteRule ^(.*) https://google.com/$1 [R]

It redirects me to google. I don't understand why this is happening though. Even with no .htaccess file, it causes a redirect loop. I was trying to disable the OPTIONS thing earlier (telnet to my site, port 80, type OPTIONS / HTTP/1.0 <hit enter twice> and have it show something besides returning a 200, but I undid all that.

Again, if I have index.html, it loads just fine and works just right. Originally, I had an AddHandler thing in the .htaccess file, forcing html files to be parsed by PHP, but I removed that and even restarted the server.

These are the request headers and the response headers I'm getting:

Request Header
GET / HTTP/1.1
Host: www.jetbbs.com
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.109 Safari/537.36
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
Cookie: timezone=America/New_York

Response Header
HTTP/1.1 302 Found
Date: Fri, 19 Feb 2016 22:40:07 GMT
Server: Apache
Location: https://www.jetbbs.com/
Content-Length: 207
Connection: close
Content-Type: text/html; charset=iso-8859-1

[Spork Schivago]

Re: Looking for exploits on my server.

I broke my freaking site. I get

This webpage has a redirect loop

ERR_TOO_MANY_REDIRECTS

This is my .htaccess file:

# tell the browser to check for index.html and index.php, in that order.
# if either exist, load that file by default.
DirectoryIndex index.php index.html

RewriteEngine On             # Turn Rewrite Mod on

# Redirect all users to the https version of our website, because we have SSL certs now.
RewriteCond %{HTTPS} off
RewriteRule ^(.*) https://%{HTTP_HOST}/$1 [R]

This worked before, I believe. I don't know what really happened. This is my index.php file, that's all I have on my site:

<?php  echo "test"; ?>

If I remove the index.php from the DirectoryIndex statement, I see my main directory listing. If I rename index.php to index.html, I see the file and don't get the error. It's just when I have the php extension that I'm getting the errror.

So, without changing the .htaccess file, leaving it just like it is, if I have just an index.html file, it loads fine and redirects to https://mydomain.com and shows the contents of index.html. If I remove the index.html and have the php code, I get the redirect loop. Caching is turned off and this worked the other day. I've even tried in IE, just to rule out a cookie / cache problem. Any suggestions ?

[Spork Schivago]

Re: Looking for exploits on my server.

Thank you for your indepth explanation of some of the ways I can keep my database username / password secure. It's much appreciated.

For the statement about writing code multiple ways, I'll give you an example and you tell me if I don't have to do it this way.

I named my server franklin. That's the hostname. But I don't want people going to franklin.mydomain.com. I do want franklin.mydomain.com to exist though. So, if someone goes there via a web browser, I display a message that says something like, hey, if you're trying to go to mydomain.com, please use this link instead. And then it says you'll be redirected in 5 seconds and it counts down from 5 to 0 and redirects.

When I was implementing the countdown, I saw that the javascript window.location.replace(mydomain.com); function has issues with IE8 and lower. So my solution was to write special code for IE8, like this:

  <!--[if lt IE 9]><script type="text/javascript">var IE_fix=true;</script><![endif]-->
// more code that I'm not showing here....
     if(typeof IE_fix != "undefined") { // IE8 and lower fix to pass the http referer
      var referLink = document.createElement("a");
      referLink.href = targetURL;
      document.body.appendChild(referLink);
      referLink.click();
     } else { // All other browsers
      window.location.replace(targetURL);
     }

I started working on some code. I haven't uploaded it to the new server yet though. I'm trying to make it "responsive", so it's compatible with cell phones and tablets. I want a navigation bar that's at the top. I was thinking of maybe making it auto-disappear and when you bring the mouse to the top, it'll reappear. I dunno yet though on if I'm going to go that route or not. I was thinking for the various menus on the nav bar, I could store them in a database and have my code load them from the database. That way, if I want to add more items to a menu, if I write the code just right, I should just be able to add it to the database and not have to worry about touching the html files.

I also thought it might be cool if I allow users to change the colour / theme of the site. I could use a database again and store default values in there....

[mariushm]

Re: Looking for exploits on my server.

The web server detects the file extension (.php) and knows that it's a script so it passes it to the PHP engine/parser which processes the script and produces an ouput which is sent back to the web server which then sends this data to the user. So whenever a user tries to access a .php file, the user will receive something processed.

If somehow you configure the web server incorrectly and php is no longer detected as a parser/interpreter, then it's possible that the web server will send the php files to the user as text files or binary files. In this case, yes, the user may view the source code of your website.

If you're extra paranoid, you can store the username and password in a file located outside the folder that's usually accessible by the web server and include the file in your scripts with a simple include command (in the case of php). In this case, even if user is able to retrieve the php files and reads the source code and figures out where the configuration file is, that configuration file is not accessible using the web server.

If there's no way to include files from outside the web server's folder (for security reasons some hosting companies configure everything this way) you can store this file with sensitive information in a particular folder (for example "secrets" or "configuration") , have the file included in other php scripts like I said above, and you can create a .htaccess file in that folder (if you use Apache) to make the web server refuse to serve any files from that secret folder. See http://stackoverflow.com/questions/1...er-in-htaccess
Those .htaccess files in the case of the Apache web server are like the desktop.ini files in Windows, they allow creation of custom rules for the folder they're created in, or for particular files in that folder, and these rules override the rules in the main Apache configuration file (which you may not be able to edit as it's often the case on shared hosting servers). See also this : http://viralpatel.net/blogs/21-very-...s-tips-tricks/

Other web servers (like nginx for example) have a similar mechanism, a kind of scripting language in the configuration of a website, that allows you to tell the server to refuse access to a folder if some conditions are met.

I've noticed I gotta write my code sometimes multiple ways. One way for IE, one way for Chrome, one way for Firefox.

No, you don't.

You create your website in such a way that it would work with majority of browsers that respect the standards, like Firefox or Chrome. Once you're done, you can create specific tweaks or stylesheet add-ons for particular web browsers to make the website behave like it works on the standard browsers.
You don't write separate websites for particular browsers.
HTML5 should be pretty well supported, at least the basics would work (i doubt you'd make such a complex website from the start especially since you're just learning now). As for CSS, I don't think you need CSS3.
Small steps, learn the basics.

[Spork Schivago]

Re: Looking for exploits on my server.

stj, no, because programs like john the ripper use dictionaries with words like "John" and "Maria" and it tries combinations of these words but it rarely picks up to 3-4 words and tries them in lowercase and uppercase combinations and so on, or just first letter of the word uppercase and so on...
And just an extra space between two words (two spaces in a row somewhere in the passsword) would make programs like john the ripper useless.

If someone where to get my database, would they be able to use rainbow tables to help recover the passwords? I've used them on Windows machines when people couldn't remember their passwords and it's a fairly quick way to get weird passwords, so long as they're under a certain length.

Spork, the programming language has have built-in functions that allows you to escape values that you put into a sql query, which prevents SQL injections.
There's also the concept of prepared statements : https://en.wikipedia.org/wiki/Prepared_statement or see this page from the PHP manual : http://php.net/manual/en/pdo.prepared-statements.php

Also see this page about sql injection prevention : https://www.owasp.org/index.php/SQL_...on_Cheat_Sheet and also read about XSS (cross site scripting prevention) when you can : https://www.owasp.org/index.php/XSS_...on_Cheat_Sheet

I'll be reading these come tomorrow. Didn't get a lot of sleep last night.

When each account is created, generate a random code (a 'salt') and store it in a field in the database. For example, john@example.com with password 'test' will get a random code '4fhHJsaByt' and you store in the database the hash of 'test' combined with your salt in some way (append salt at end, or before password, or both)...

Back in the late 90's, Linux encrypted passwords this way. It seemed really effective so there's a good chance they still do it this way, with passwd.

Yes, if you connect to mysql with a username and password then yes, you'd have to store that user: pass in a php file somewhere. This is generally fine, because you can create a mysql user that is only allowed to access specific databases, you could even have one user:pass to read data from database tables and another user:pass to modify, delete, insert data in tables, you can configure the mysql server to only allow connections from particular IPs or only the localhost (the source code on your server) so any hacker wouldn't be able to connect from outside to your mysql server and so on ...

There's also the possibility of not using tcp to connect from php or other programming language to mysql, but rather use a socket or a named pipe instead.

So if I store the username and password in the PHP file, the users can not ever download that PHP file, because PHP is a server-side language? Or is there a program that would allow them to download the actual PHP file?

Also, if I only allow connections to MariaDB from the localhost, when users connect to my site and the PHP code runs, the PHP code will still be able to access the database, because PHP is server side...but the users won't be able to, right? So even if they do get the username / password, they just won't be able to download the database...unless of course they do some weird stuff...and that's where writing the good code comes in, escaping shit and all that. I think I'm finally understanding all this. I appreciate all the help from everyone.

I'm sure I'll have more questions. I tried finding a programming site for web development to ask questions like this before....I found some but I couldn't really get any answers to my questions. It seems there wasn't really a lot of people working on answering the questions but a lot of people asking them! I wonder if anyone has any good suggestions on some free books or maybe even good ones I gotta buy to learn how to write good code. I don't know HTML, I do know a little bit of PHP (it's a lot like C, so I'm good there). CSS, I don't know a lot of that either. I've noticed I gotta write my code sometimes multiple ways. One way for IE, one way for Chrome, one way for Firefox. And of course, there's always that question, how old of a browser do you support? Something less than IE8? I wanted to write in that new HTML5 and CSS3 but I'm not sure how many browsers fully support that yet.

[mariushm]

Re: Looking for exploits on my server.

stj, no, because programs like john the ripper use dictionaries with words like "John" and "Maria" and it tries combinations of these words but it rarely picks up to 3-4 words and tries them in lowercase and uppercase combinations and so on, or just first letter of the word uppercase and so on...
And just an extra space between two words (two spaces in a row somewhere in the passsword) would make programs like john the ripper useless.

Spork, the programming language has have built-in functions that allows you to escape values that you put into a sql query, which prevents SQL injections.
There's also the concept of prepared statements : https://en.wikipedia.org/wiki/Prepared_statement or see this page from the PHP manual : http://php.net/manual/en/pdo.prepared-statements.php

Also see this page about sql injection prevention : https://www.owasp.org/index.php/SQL_...on_Cheat_Sheet and also read about XSS (cross site scripting prevention) when you can : https://www.owasp.org/index.php/XSS_...on_Cheat_Sheet


So for the database, don't store the password. Store a HASH of the password and when a user goes to login, whatever password they type, recreate the HASH and see if they match? I know there seems to be a lot higher collision rate for MD5 than previously thought. I wonder if using something like SHA-256 would be feasible or would that be a bit over-kill?

When each account is created, generate a random code (a 'salt') and store it in a field in the database. For example, john@example.com with password 'test' will get a random code '4fhHJsaByt' and you store in the database the hash of 'test' combined with your salt in some way (append salt at end, or before password, or both)

When user logs in, he sends the password, you code combines the password with the salt and compares the result against the hash stored in the database.
This way, if two users use the same password, the hashes will be different due to the salt which is random and therefore should be different for each user.

Anyway, I'm looking into switching to MariaDB. I'm running a very old version of MySQL, version 5.5.

The main developer of MySQL sold it to Oracle a few years ago, with the stipulation that there always has to be an open source version of MySQL or something like that.
He then went on and started MariaDB which is based on the MySQL source code but on top of that he added a lot of improvements that make the engine faster.
As far as I know, each time Oracle goes and makes some updates to MySQL he makes sure MariaDB is 100% compatible with MySQL so it's perfectly safe to replace MySQL with MariaDB
It shouldn't matter which version of MariaDB you install... look at the recent changes or version history of MariaDB and see if there's some serious changes between those versions, that would force you to use a specific version. I doubt there's any.

PHP is a server side language, right? Let's say I have my MariaDB database setup and in my PHP code, I connect to the database, with a username and password. I would need to have the username and password in the PHP script. Is there anyway for someone to download that PHP file to grab the username / password? How do people normally do this? Thanks!

Yes, if you connect to mysql with a username and password then yes, you'd have to store that user: pass in a php file somewhere. This is generally fine, because you can create a mysql user that is only allowed to access specific databases, you could even have one user:pass to read data from database tables and another user:pass to modify, delete, insert data in tables, you can configure the mysql server to only allow connections from particular IPs or only the localhost (the source code on your server) so any hacker wouldn't be able to connect from outside to your mysql server and so on ...

There's also the possibility of not using tcp to connect from php or other programming language to mysql, but rather use a socket or a named pipe instead.

[Spork Schivago]

Re: Looking for exploits on my server.

that bit using common word combo's is bullshit.
most people will smash that with a dictionary file and "john the ripper"

So for passwords, would I have to worry about that? My system is setup in such a way where if someone tries connecting a bunch real quick like, it permanently bans them...if their IP address is changing (ie, a bot net), I don't think I can protect easily against that. I can disable an account if someone tries x amount of times to get in. That could help against that. I should probably set some requirements on the password I guess.

PHP is a server side language, right? Let's say I have my MariaDB database setup and in my PHP code, I connect to the database, with a username and password. I would need to have the username and password in the PHP script. Is there anyway for someone to download that PHP file to grab the username / password? How do people normally do this? Thanks!

[stj]

Re: Looking for exploits on my server.

that bit using common word combo's is bullshit.
most people will smash that with a dictionary file and "john the ripper"

[Spork Schivago]

Re: Looking for exploits on my server.

No, absolutely not.

The proper way to do it is to accept what the user gives you (and make some basic checks like making sure the name is not longer than 100 characters or something like that) and ESCAPE IT before sending it to the database using a mysql query.

Also, you make sure that you ESCAPE various characters when displaying the name on screen, characters that may otherwise be interpreted by the web browser as HTML codes (you don't want < or > to appear in the html page because browser may think you open or close a html tag.

You can go further if you want and NORMALIZE a name (or any user entered text) to a specific canonical form, for example NFC ... see this : http://www.macchiato.com/unicode/nfc-faq
This would make it easier to check for already existing name or to search in particular text.


A person's name is something very personal and some people may be offended if you restrict them to using only specific characters to write their name. See this for lots of reasons why name fields should just accept any text: http://www.kalzumeus.com/2010/06/17/...e-about-names/

You will also irritate them if you make a form that forces them to enter addresses in a particular way, there's all kinds of addresses: https://www.mjt.me.uk/posts/falsehoo...out-addresses/

You may restrict user into using only specific characters or symbols for specific fields like passwords but even there you have to be careful because for example a password like "car duck singing WHEELS" is much stronger than "sdfd3$!!" :



If you force people to always use a number in the password and always use at least one uppercase letter, you're even worse, you're basically guaranteeing that user will save the password somewhere or reuse a password he/she uses somewhere else, defeating the purpose of your password.

Anyways, restricting people from typing anything in a password field is stupid in the first place because any sane programmer would NOT store the password in the database, they'd store a HASH of the password , a code generated from the password that's (kind of) unique .. even a single character changed in the password would produce another hash.
See this page for a good explanation about hashing passwords: https://crackstation.net/hashing-security.htm

Okay, I have some questions now. First off, is there a list of characters that should always be escaped or could that vary depending on what software I'm using (like MySQL vs PostgreSQL)? I wonder if there's any libraries that I could use that would parse the username / password / filename stuff automatically for me or if I should write it myself.

So for the database, don't store the password. Store a HASH of the password and when a user goes to login, whatever password they type, recreate the HASH and see if they match? I know there seems to be a lot higher collision rate for MD5 than previously thought. I wonder if using something like SHA-256 would be feasible or would that be a bit over-kill?


Now, my last question! I take everyone's advice very serious, especially with this website stuff. Although I majored in Networking, the teacher was horrible and the only networking professor we had. During the fourth CCNA semester, we were supposed to learn about security, active directory and Linux. Instead, we learned how to use DOS. For the CCNA classes, the professor would just have us use the internet to google the questions, word for word, to get the answers. We weren't allowed to go until we scored a 90 or higher on the tests. But we couldn't answer the questions without googling because we never learned the info.

Anyway, I'm looking into switching to MariaDB. I'm running a very old version of MySQL, version 5.5. I have the following options:
Upgrade to ->
MySQL 5.6
MariaDB 10.1
MariaDB 10.0

Is it safe to go directly from MySQL 5.5 to MariaDB 10.1? MySQL 5.5 was released about 5 years before MariaDB 10.1. Also, if I upgrade, there's no way to go back without completely restoring the whole server from a backup.

[Spork Schivago]

Re: Looking for exploits on my server.

check input buffers for anything stupid.
that's the simplest thing that nobody seems to bother with anymore.

names for example should only contain ascii and only a-z,A-Z and 0-9.
anything else should be wiped or refused.
also check the input buffer for some fuck trying to push several k or even meg into it to cause an overflow in the parsing routines!

There's gotta be a better way than just a-z, A-Z and 0-9. When I worked in a data center as a programmer, we'd get foreign names that had weird characters in them. Is there a safe way to accept those? I'd like my site to be usable by anyone in the world. I think foreign characters might be doable using something called UTF-8 encoding, but I haven't checked into that yet.

[mariushm]

Re: Looking for exploits on my server.

names for example should only contain ascii and only a-z,A-Z and 0-9.
anything else should be wiped or refused.
also check the input buffer for some fuck trying to push several k or even meg into it to cause an overflow in the parsing routines!

No, absolutely not.

The proper way to do it is to accept what the user gives you (and make some basic checks like making sure the name is not longer than 100 characters or something like that) and ESCAPE IT before sending it to the database using a mysql query.

Also, you make sure that you ESCAPE various characters when displaying the name on screen, characters that may otherwise be interpreted by the web browser as HTML codes (you don't want < or > to appear in the html page because browser may think you open or close a html tag.

You can go further if you want and NORMALIZE a name (or any user entered text) to a specific canonical form, for example NFC ... see this : http://www.macchiato.com/unicode/nfc-faq
This would make it easier to check for already existing name or to search in particular text.


A person's name is something very personal and some people may be offended if you restrict them to using only specific characters to write their name. See this for lots of reasons why name fields should just accept any text: http://www.kalzumeus.com/2010/06/17/...e-about-names/

You will also irritate them if you make a form that forces them to enter addresses in a particular way, there's all kinds of addresses: https://www.mjt.me.uk/posts/falsehoo...out-addresses/

You may restrict user into using only specific characters or symbols for specific fields like passwords but even there you have to be careful because for example a password like "car duck singing WHEELS" is much stronger than "sdfd3$!!" :



If you force people to always use a number in the password and always use at least one uppercase letter, you're even worse, you're basically guaranteeing that user will save the password somewhere or reuse a password he/she uses somewhere else, defeating the purpose of your password.

Anyways, restricting people from typing anything in a password field is stupid in the first place because any sane programmer would NOT store the password in the database, they'd store a HASH of the password , a code generated from the password that's (kind of) unique .. even a single character changed in the password would produce another hash.
See this page for a good explanation about hashing passwords: https://crackstation.net/hashing-security.htm

[stj]

Re: Looking for exploits on my server.

check input buffers for anything stupid.
that's the simplest thing that nobody seems to bother with anymore.

names for example should only contain ascii and only a-z,A-Z and 0-9.
anything else should be wiped or refused.
also check the input buffer for some fuck trying to push several k or even meg into it to cause an overflow in the parsing routines!

[Spork Schivago]

Re: Looking for exploits on my server.

Thanks for the suggestions on MariaDB. So all the MySQL commands will just work? There might be some special MariaDB specific commands, but at least all the MySQL commands will work?

I almost went for the fully self-managed server option but I really struggle with the DNS stuff. I've read up on how to set records more than a few times but I always get really confused for some reason. I don't think I'll ever fully understand those dang records.

Glad to know PHPMyAdmin is secure, even though it's outdated.

So, we've talked a bit about SQL Injection and someone said just write good code. What would be a good example of badly written code? Like maybe when someone creates an account, I don't check for special characters and somehow a person enters a name and a MySQL command and my PHP code might come to some delimiter or special char and think that's their name, and then execute the MySQL code?

Like,
username: SporkSchivago;!*DELETE MYSQL STUFF!
?

[shovenose]

Re: Looking for exploits on my server.

You can use a panel like ajenti-v that has many less features. Its probably more secure. But you're not going to get hacked due to phpmyadmin...

As for mariadb, its a drop in replacement for mysql that has much better performance, and its a few clicks to upgrade, so definitely use it.

If you have one site just do it all manually any control panel is a waste. If you have multiple sites cpanel, etc. Are very handy.

[stj]

Re: Looking for exploits on my server.

MySQL is obsolete.
the guy who wrote it fell out with the company and branched off on his own.
the latest is now called MariaDB
https://mariadb.org/

of course idiots will still buy sql licenses from m$ and other bandits!

[Spork Schivago]

Re: Looking for exploits on my server.

You're wasting your time trying to remove phpmyadmin, etc.

Okay. You think it's secure? I noticed it's outdated and probably won't be upgraded for a while. It seems cPanel used to provide a newer version but then discovered it required MySQL 5 or higher. So instead of providing an upgrade to MySQL, they just downgraded PHPMyAdmin. It seems a lot of the software with cPanel is a bit old. I'm almost thinking of just doing away with the managed part of my server and fully managing it myself, with no cPanel / WHM.

[shovenose]

Re: Looking for exploits on my server.

You're wasting your time trying to remove phpmyadmin, etc.

[Spork Schivago]

Re: Looking for exploits on my server.

To avoid SQL injection ensure you code your site properly. The main one being constrain the inputs.

Okay. I noticed there's databases that cPanel uses. There's also stuff installed that I don't use but might be required for cPanel to function properly. Like phpAdmin I think it's called. It appears to be some web based interface for managing SQL databases. I prefer to do stuff from the command line. When I found it was installed and running, I went there, and found a bunch of databases that various services were using. To me, if I'm not using it, I don't think it should be installed. Just another potential way for someone to get in. What do you guys think?

[Spork Schivago]

Re: Looking for exploits on my server.

If the BBC can be floored by a DDoS, then your VPS has no chance.
http://www.csoonline.com/article/302...n-history.html

To avoid SQL injection ensure you code your site properly. The main one being constrain the inputs.

Thank you. I figured there's not much I can do without paying for special (expensive) DDoS protection to be impervious from heavy DDoS attacks. What I was mainly interested in protecting from people that might not have a giant botnet or something. I'm pretty sure I was already hit by a DoS / DDoS when I had a shared virtual server. I logged into this chat room to ask for help with some jquery stuff. The main guy asked who I was going through for hosting and I said GoDaddy. Once I made the changes, he wanted a link to my domain so he could check it out. He was talking about how GoDaddy's security isn't that good and I said I thought it was pretty decent. I told him how if someone tries to do something bad, they automatically get blocked (I had no control over this. This was something that GoDaddy had setup). And then all of a sudden, he says he cannot connect to my domain. I tried connecting, nothing. After about 2 minutes or so, I could get back on and I told him I was going to check the logs to see what happened and he said there wouldn't be anything in my logs. It'd be in the logs on the main node or whatever it's called. I had wondered how he knew there wasn't going to be anything in my log and I felt like maybe he initiated some sort of DDoS but couldn't prove it or anything.

For the IMAP STARTLS stuff, I might of fixed it. I changed Allow Plaintext Authentication to no. This is what it says about the setting:

This setting will allow remote email clients to authenticate using unencrypted connections. When set to “no”, only connections originating on the local server will be allowed to authenticate without encryption. Selecting “no” is preferable to disabling IMAP in the Protocols Enabled section since it will force remote users to use encryption while still allowing webmail to function correctly.

I'm a bit confused about, "Selecting "no" is preferable to disabling IMAP in the Protocols Enabled section..." Does that mean users who have e-mail accounts won't be able to use IMAP?