Here, /g/, I've made a simple 8ball web app as practice to learn PHP and MySQL,
and I've decided to share it with you guys. It will remember past questions and
return the answers it previously determined.
https://nonfree.pizza/8ball.php
The web page shows up properly in every browser and contains absolutely no
nonfree javascript or any scripts you're expected to run for that matter. For
people who prefer it, there is an even simpler method to ask the magic 8ball
questions. Just POST it as q to https://nonfree.pizza/8ball.php and it will
respond with no HTML, just the answer. For example:$ curl -d q="Should I install Gentoo?" https://nonfree.pizza/8ball.php
The 8ball says:
Do you really need me to tell you that?
$
This saves on bandwidth if you're in a location with bad internet or an
applications developer.
Suggestions welcome. I hope at least someone on here finds value in it.
root@server:~# curl -d q="will i get pussy tonight?" https://nonfree.pizza/8ball.php
The 8ball has determined:
There's no question about it.
root@server:~#
thanks 8ball
>>54755781
>Here, /g/, I've made a simple 8ball web app as practice to learn PHP and MySQL
>Web app
Also why the fuck do you need a database or PHP for something that could be done in Javascript? Or a single line or perl?
>>54756213
>javascript
Why would I want to trust the client to determine the answer? I'm storing the answers for future responses, so why wouldn't I do it serverside?
>Why does the botnet want me to starve?
It wouldn't be right for me to reveal this.
ok
OP do you want to suck dick?
reminder that this website logs your inputs and it has no privacy policy, so don't go putting shit like your SSN in there
>>54757011
If you use POST I can't see anything fyi
Questions are stored as hashes
>>54757022
then how did you know that someone did or did not attempt SQL injection
>>54757052
Just look at the questions in database.
>>54757070
but you said they're stored as hashes
>>54757052
Because they used HTTP GET. I'm watching nginx's access logs, and anything asked via the website uses GET, so if you want to ask something personal, you should use the POST API instead.
>>54757070
Questions are stored as hashes, to prevent SQL injects and in case the database gets compromised.
>>54757076
That's not me.
>>54757076
Believing what people tell on the Internet. Are you retard?
>>54757090
>hashes, to prevent SQL injects
lol
>>54757117
I didn't feel like doing anything fancy like parameterized queries or stored procedures for this. Hashing just werks.
>>54757137
You can escape the string. PHP has a function for that.
>>54755781
https://nonfree.pizza/8ball.php?q=is+op+a+faggot
10/10
gib src
>>54757207
I figured I wouldn't waste the cycles, since the hashing was for security reasons/practice anyway. If everything's hashed before lookup, why bother sanitizing?
The only touching up I do is trimming extra spaces and other duplicate checks, and htmlspecialchars() for when the question is added to the page.
>>54757090
>if you want to ask something personal, you should use the POST API instead.
Why would I want to ask your shitty website something personal?
>>54757252
I agrre that hashes protect from SQL injection, but I would never use hashes to protect from injection. "It's an implication, not an equivalence."
>>54757137
>parameterized queries
>fancy
Hashing is slow and costly
>>54757295
Someone did ask it "my SSN is XXX-XX-XXXX" which isn't a question but whatever floats you're boat I suppose.
>>54757308
Hashing is supposed to be slow and costly. Since there's no reason to store the questions themselves, I hash them in case some clever cracker steals the 8ball's answers and reveals them to the world.
>>54757137
You could also use prepared statements which are just as quick to write as a normal statements.
>>54757207
Escaping strings from the client does not guarantee protection against SQL injection.
>>54757373
>Escaping strings from the client does not guarantee protection against SQL injection.
How? I'm interested. Explain to me.
>>54757373
I will probably play around with more secure methods, like I said this was a simple practice and the first PHP app I made of any significance.
>>54757396
At work and posting from phone, so I cannot link examples or sources. You can Google this yourself.
In short, when I started doing php development (2 years ago), I learned about SQL injection and how to prevent it/best practices.
One of those best practices is to not escape strings. It can mess up input data and mess up displaying the data later on a webpage. On top of that, there are tricky ways to get around escaped strings to perform SQL injection such as abusing Unicode. There are multiple ways to escape strings in php for dB insertion, each way has different caveats.
Because of this, I decided I would just use prepared statements on all data that comes from the client and not worry myself over escaping or sanitizing client data.
>>54758013
>displaying the data later on a webpage
You have to unescape the string for displaying.
>escaped strings to perform SQL injection such as abusing Unicode
It won't mean that escaping is a bad idea, it would just show that the escape function is incorrect. And the spec of the database must be read to see what can begin and terminate a string. And the database must obey its own spec.
In any case escaping is not a bad method. There just bugs that need to be fixed.
By the way the MySQL escape function in PHP is reliable.
>>54758071
>You have to unescape the string for displaying.
I am aware. When you start escaping strings, you'll have to do it to all strings to ensure consistency as well as ensure you're unescaping all data retrieved from the db.
>In any case escaping is not a bad method. There just bugs that need to be fixed.
Escaping works as intended. It can have some unintended results though, so I avoid it.
>By the way the MySQL escape function in PHP is reliable.
One Google search brought up an example where injection can get through. They exist but they're very rare edge cases.
>>54755781
>>You're
>>54759310
Gee, thanks anon, I hadn't noticed.
