Tag Archives: PHP

PHP Regex tutorial

Have you ever wondered how web applications do validation on forms? How does the app know when your input is really an email address? In most PHP applications, this is done using regular expressions (Regex).

I’ve previously posted about how to defend against XSS and SQL injection. Checking strings with a white list of allowed characters is one of the easiest changes a developer can make. Regex makes this easy in most programming languages.

In that post I linked to RegexOne. The site had a pretty good cheatsheet covering how regex is useful. This is only really helpful if you are familiar with how regex works.

If you’re looking for a more complete tutorial, try his. Guru99 has reached out to me to promote their new tutorial: PHP Regular Expressions Tutorial: Preg_match, Preg_split, Preg_replace. It looks like a pretty comprehensive tutorial. I suggest looking at that to learn some of the basics behind regex.

Monitoring Honeypot Output

Last week I posted in Hacking about installing a Honeypot to record SSH traffic. Since it was installed, I’ve been working on easily monitoring of the output. Michel Oosterhof, the creator of Cowrie, has done a lot of development work to create some awesome logging output from the honeypot. There are a lot of different options and you can even store output in a mySql database. I found instructions for that on a wordpress blog. Feel free to checkout the current page at greenjam94.me/honeypot.html

First Attempt

After setting up my mySQL, I wrote a page of php functions to run about 8 different queries to get back information I thought was relevant. At first, the page was as simple as possible, the same page with all those functions also displayed the front end. It was a late night rushed kind of job, but you could see some pretty cool stats, in the first 24 hours of the site, we had over 500 attempts to establish a SSH connection to the honeypot. I linked the php page to my website and was happy for the night.

Second Attempt

After looking at the page for a while, the load page took forever, it also didn’t look that good. For one thing, the code was horrible. I had so many php echo statements where there were paragraphs of unformatted HTML. The front end web page was a clear reflection of that. My goal of my second attempt was to make the webpage load fast, even on mobile devices. To accomplish that, I moved all the html to an actual html file and used Javascript and AJAX to bounce requests to the old PHP page.

AJAX

It’s not anything new, but the site loads immediately and info fills if possible. If for some reason the PHP fails, the site doesn’t break, the page simply doesn’t display that part of the content. With the page being more formatted it was easier to make design changes. The site is slightly more responsive and mobile friendly thanks to better implementation of the Bootstrap framework.

IP Info

The website also uses ipinfo.io to get more information about where an IP address is located, right now the page is only displaying Country Codes, but the idea is to display the IP addresses over a map. Wouldn’t that look really cool? I want to use something like d3 but I haven’t had any experience with it so it may take a while. It’d be nice if it could look like this cesium example.

VirusTotal

Our honeypot is monitoring traffic and we see results, but we aren’t doing anything with them. Files and uploads are saved so it’s possible to analyze things further. VirusTotal is a website with a public API to review IP addresses and files for viruses and malicious code. One of my future goals is to set up a connection to the API to turn in anything that gets uploaded through the honeypot. The only issue I see is that filenames get changed, and VirusTotal doesn’t like that. The name is changed to a hash of information about the session that uploaded the file.

Future Plans

Better use of IpInfo and VirusTotal are the next steps to improve the site. After that I’ll work on improving the site in other ways. Right now, the honeypot is logging through regular log files, JSON, and mySQL. In the five days it’s been running, we’ve had over 1,000 sessions and logging those in triplicate might get expensive on the hard drive. It’d be more efficient to write the PHP backend to pull from the JSON logs instead of needing the SQL database.

COGSS Website: Automated Scoring for Collegiate Gymnastics

I’ve mentioned in previous posts that my girlfriend is on a gymnastics team. I did their club website for them a while ago. I went to a meet they hosted their year and helped out as much as possible. They were using a Microsoft Excel sheet to do all of their scoring for each event. While watching the guy use excel, I got a headache just trying to follow the complex steps that were set up for it… so I had the bright idea to set up a website that simplifies the process and allow anyone to use it for their meets as well.

At first I made a site of my own design and tried to recreate the excel sheet as best I could from memory. When I completed the site, it got less then a warm welcome from my girlfriend’s gymnastics team… in fact she was the only one to say anything about it to me. So here I am, completely redesigning the site and discussing wireframes with her. I plan on redoing the site and following NAIGC rules for the scoring.

The next competition is in the spring of 2016. I hope to finish the project this summer. I’ll update this post when it’s completed.

Developing KORA 3.0

This is a big project I’ve worked on from the beginning when working at Matrix: Center for Digital Humanities & Social Sciences. It’s taking an old platform and revamps it into a modern application. KORA 1.0 was built over the last two decades by non-software developers, I never saw the code personally but I heard horror stories of unorganized pages of code that was thousands of lines long.

KORA 2.0 reorganized the code into an Object-Oriented-Programming (OOP) format, Matrix’s system admin (now retired) and students introduced classes and actually made the code readable to developers. The current release of KORA (2.6.3) is the latest version we have released to the public.

If you’re still asking, what the heck is KORA anyways? Well, it’s a african instrument.

But the application is a way to store analog data (Pictures, books, interviews, etc) into a digital database. Picture if you will, a way for non-developers to create, update, and use a database without even realizing it.

KORA 3.0 is using a PHP framework called Laravel to further improve the code layout. We’re introducing a MVC layout to separate content pages, objects and actions, and controllers. The plan is to also restructure the database tables and format all the classes to match a theme to make it easier for new students to continue developing it. KORA 3.0 will implement the latest and greatest there is to offer including HMTL5, CSS3, RESTful APIs and more.

Defend your website against SQL injection and XXS

Hey everyone, so at work we’ve had a couple vulnerabilities pop up so I was privileged with writing this up and I wanted to share it with you. I hope you find it interesting! Sorry it’s such a long read. There’s two parts, one for SQL injection and one for Cross Site Scripting.

SQL Injection
Check out SQL injection on OWASP

SQL injection is, simply put, a user adding additional requests to your database calls. For instance if you ask for a search term and compare that term to the database with something like:

SELECT title, author, text FROM books WHERE text LIKE ‘%$input%’

Developers can defend against SQL injection by validating all inputs. This means that we use a function that strips away characters that is required to run SQL from that input.

validateInput() would be a function we define that removes characters such as
*, `, or “. Something else to put in your validateInput() function would be PHP’s  MySQLi escape function. It’s also wise to not allow Users to type in what tables they want to access in the database. Use separate queries instead of a dynamic one.

One of the simplest ways to test your inputs is to add ” or 1=1” to the end of the input. If we put ”’something%’ OR 1=1”’ into the example above we get:

SELECT title, author, text FROM books WHERE text LIKE ‘% ”’something%’ OR 1=1”’ ‘

Cross Site Scripting (XSS )
Check out XSS on OWASP

XSS is similar to SQL in the sense that a user is trying to add their own code to our website. This time instead of affecting our database, it’s adding a javascript script (or a similar tag) to our pages code. Do you know what this is below?

%3C%2Fh2%3E%3Cscript%3Ealert%281%29%3B%3C%2Fscript%3E%3Ch2%3E

It looks like a lot of gibberish to me! While we don’t expect our normal users to type this into our log-in field, a hacker wouldn’t hesitate. While it looks like nothing, this is actually the HTML escape characters for <script>alert(1);</script>. The user just added their own javascript to our website!

Just like the input we use for SQL queries we need to validate all inputs! I can’t say that enough. If the page is grabbing something, we need to pass it to a function that strips out anything illegal. In XSS’s case, we want to remove anything that is or could be a tag.

Our validation function needs to remove all tags, and the easiest way to do that is with PHP’s strip_tags function!

Want to see if you can add your own javascript to the website? Use the alert(1) from above. It’s harmless and has a nice visual to show you
that your site is indeed vulnerable to XSS.

In Review
* In general, assume that all users are vicious hackers trying to break your brand new website.
* Do NOT use user input for HTML comments, scripts, attributes, or CSS. ”’EVER”’
* Consider hiding SQL errors on live sites, Hackers use the information to understand the database layout.
* When taking input from a user, minimize their possible choices as much as possible.
Example: Ages – Should only be positive whole numbers, no special characters.
Example: Email – Should be a string @ string . string. Now might be a good time to learn regex
Example: Names – Should NOT have punctuation or special characters.