requinix

Have you looked at the HTML source of the page? To confirm that the links really are not being outputted, as opposed to some CSS issue that's hiding them from you?

What?

Almost: 4.19 * first 75 units (314.25) + 5.72 * next 92 units (526.24) + 30 flat charge = 870.49, +5% VAT = 914.01

Did you mark your own post as being "the solution" because you figured out the answer yourself? Or are you still having problems?

Most "hacks" are people gaining access to a database by way of SQL injection. Encryption would help because they can't get the encryption key - just the data. Of course the problem with encryption is that if you lose your key then you lose everything. Irrevocably. Plus the obvious drawbacks of having to encrypt and decrypt stuff all the time. Shared hosting is itself a risk, too. Can you move off it? Besides the dedicated environment being more secure, you can also mitigate SQL injection attacks by moving the database off to another server - one not exposed to the internet - and on this same server you also put a simple webservice that gets and stores customer data. Essentially, you make API calls to yourself when you need that data.

No. You can't see the forest for the trees. This is a really, really basic and fundamental question about what files are and what file_get_contents does. The kind of thing that I would expect you to know the answer to, if not for the fact that you're in up to your neck in something you don't understand.

With ^([^/]*)$ then /vojvodjanski.html -> index.php?c=vokvodjanski.html 1. Make the .html optional so that /vojvodjanski.html will continue to work and you do not create 404 errors for old URLs that are still being used. 2. Make the last [^/]* -> [^/]*? because * will match "everything" but *? will match "until". RewriteRule ^([^/]*?)(\.html)?$ /index.php?c=$1 [L] 3. You must change the URLs on your site to not use .html. Because mod_rewrite will not change your website for you. <a href="/vojvodjanski">

RewriteRule ^(hu)/([^/]*)\.html$ /index.php?lg=$1&c=$2 [L] This URL is very similar to the /vojvodjanski/drustvo.html because they are both "/" + word #1 + "/" + word #2 + ".html". If you want word #1 "hu" to be special then you must put this RewriteRule before the [^/]+/[^/]+.html RewriteRule. If you want another language, like sk, then RewriteRule ^(hu|sk)/([^/]*)\.html$ /index.php?lg=$1&c=$2 [L]

I don't know how any of that would help - at least not in an automated way. If you want to remove "hidden scripting" then use an image processing library that can deal with the image and strip out everything else that doesn't matter. However that doesn't eliminate the possibility of someone going through a whole lot of effort to create a plain image whose compressed data contains a malicious string. If that's even possible to do. You cannot protect yourself against everything. You can protect yourself against things that actually matter.

Oh dear. A raw image from a camera is where it records, with its electronic circuitry, the "colors" of each "pixel" that it can measure. It records that in a file in the very most basic way that "pixel X,Y is color Z" can go. Raw image files are large because there's a lot of data. To deal with the file size, images are compressed. If I write "computer computer computer" that takes 26 characters, but if you and I agree on another representation of words, I could compress the message to something like "3x computer" and 11 characters. Lossless PNG images work the same way. I could compress it even further as "3x cmptr" (8 characters) by stripping out the vowels, thus losing some information but still leaving enough that you know what I'm trying to say; lossy JPEG images do that. That takes care of the image itself, however images have more information than that: GPS coordinates where it was taken, camera model information, etc. That has to be represented in a way that doesn't conflict with the image data. The easiest way to do that is to say, inside the file, "The next piece of information is the GPS coordinates: (...). The next piece of information is the camera model's name: (...). The next piece of information is the compressed image data: (...)." PNG and JPEG and such images dictate compression but they also dictate how those blocks of information are arranged, and software capable of reading them will know how to read each block - or perhaps how to skip each block it doesn't care about until it finds the one(s) it wants. The information in each block can vary: the GPS coordinates block may have two 32-bit floating point values for the latitude and longitude, the camera model name may be a string value, and obviously the image data is image data. Consider one of the simplest attack vectors: PHP code inside a string-type data block. I could take a real image, add a "camera model name" block, and specify as the name the string "<?php phpinfo(); ?>". That's perfectly valid to do. I could then take that image, rename it from bad.png to bad.php, and try to upload it. Unsafe image uploading code will attempt to read data about the image, discover that the file is a very legitimate PNG, and upload it to a location like /uploads/requinix/bad.php. See how it kept the same file name and extension? I could then go to the website, go to /uploads/requinix/bad.php where the site thinks is going to be an image, but the .php extension will be run as PHP code and I'll get phpinfo() output. You can protect yourself against those attacks by following best practices about file uploads - most significant being determining the appropriate file extension on your own instead of trusting the uploaded file's name to be correct. More complicated are attacks that target specific image parsing code. Not your website itself, but the software that knew how to read PNG images directly. I'm not going to go too deep into this because it's complicated. Remember the camera model string? There's one question about how it works: where does the value of the string end? The two typical answers are that the length of the string is included (so "camera model block" + string length + string) or that the string is terminated by a special character (like NUL \0). So what happens if you don't obey that rule? I might take that bad.png I created before, load it into a special editor, and break the string (by altering the string length value or by removing the \0). With appropriate adjustments I might be able to trick an image parser into doing things it isn't supposed to do. You cannot protect yourself against those attacks, practically speaking.

If you're looking to hire someone to do this work for you, the Job Offerings forum would be a more appropriate place. If you want help doing this yourself then you can start by explaining how you tried to fix the code and what happened when you did.

Are you sure the user that the web server is running as has the permission to create tasks under the SYSTEM account? See if you can create one without any associated user information.

And your question is...?

A few ways of tackling the problem. The one that probably makes most sense for how you've set this up so far would be the simplest one: add a column to your "mad" table for the final phrase. If you don't have one already, there should also be an AUTO_INCREMENT ID in that table so you can easily refer to specific rows - this column is dealt with for you so you don't need to come up with values or put it into your INSERT queries. Then you'll need to get that phrase. Right now you just output it, so change that process so (1) you store the phrase in a string variable and then (2) you echo that. Depending on what values you pick for your madlib, you may or may not discover that you can't use $name and $adjective and such after you've escaped them. Try it: pick a name like "O'Malley" or a noun like "my father's shoe" and find out what happens. See the backslash in front of the quotes? $name and such as fine for using in a SQL query but that's because their values have been altered, and that will interfere with you trying to put it into a sentence. To fix that you should forget about mysqli_real_escape_string and instead switch to prepared statements. What you do with your $sql now is combining SQL syntax (parts like the INSERT and the list of column names) with data (the parts of speech) and this has the potential to confuse MySQL if something in the data isn't quite right. It's why you have to use mysqli_real_escape_string - but then you have the backslashes. There are simple ways to resolve that, but the best way is a prepared statement: instead of combining syntax and data, it keeps them separate and tells MySQL "here's the query and here are places where you need to use a piece of data". No combining them means no confusion. Prepared statements are easy: look here for a reference that tells you how to use ->prepare and ->bind_param and ->execute. With all that in place, you should have: 1. A string variable for the phrase that has all the data inserted into it. Make sure it looks right when your words have apostrophes. 2. A "mad" table that has columns for an ID, name, adjective, verb, noun, and the final phrase. 3. An INSERT query that mentions the phrase column (but not ID) and uses question marks for where the different pieces of data go. 4. Code that ->prepare()s the query string you had, ->bind_param()s the different variables (the data coming from $_POST directly is fine, and the string phrase), and ->execute()s. That's enough work to start with. When that is in place, look in your database to see that it's inserting everything correctly. Then post your code, we'll look over it, maybe have a suggestion or two, and then move on to the next part: the random link to a previous story (this will be easy), and/or the random story from previous values (this will be more complicated because we should do some more changes to your database to help with it).

You mean are most questions we get here about Javascript? No, it's mostly PHP, but it's mostly PHP in a web context. As in PHP is running on a website and people are visiting it in their browser. Which means Javascript is an option. But sometimes there are non-web PHP questions. I don't know which one of those this thread is yet... If you want to run something every X minutes then the standard answer is to use cron: every *nix server has it, it runs in the "background", meaning it's not driven by or reliant upon users taking specific actions (such as "keeping the browser open so something can do AJAX requests"), and you can still do just about anything you want with PHP. For the 30 minutes one, you make a script that runs whatever database queries it needs. I don't know what it's supposed to do if the value changes? Then you tell the server (exact steps vary) that you want to run some command-line program (ie, PHP with the path to your script) every 30 minutes. For the 10 minutes one, you make a script that runs whatever database queries it needs. Then you tell the server you want to run a second program (also PHP) every 10 minutes.

What are these two pieces of code that have to run at the same time? Do they have output? Where is the output supposed to go? Is this something that would be better served by running two concurrent AJAX requests on the client side?

You're going to have to explain that, because 99.9% of the time the correct solution is include/require.

/vojvodjanski.html -> /index.php?c=vojvodjanski /vojvodjanski/drustvo.html -> /index.php?c=vojvodjanski&kategorija=drustvo /hu/vojvodjanski.html -> ???

What index.php URL are the versions with /hu/ supposed to rewrite to?

A better explanation, but that isn't the problem. As I see it, you're trying to walk the line between security and no security, and you keep falling over onto one side or the other. There's only one thing I can think of: a subdomain. Your sensitive cookies are restricted to the main domain, user scripts run out of the subdomain, and the main domain does CORS as needed.

My point is that it's only possible to validate and protect oneself against things that are known. Someday, someone will come up with a new attack and wasn't being protected against because it wasn't known about. Do you let strangers come into your home and use your toilet? Before your next post where you shotgun another dozen questions at me, try to find the answers yourself. I only have so much time in the day.

Validated it fully as far as you know. Unless you consider malicious effects on the client, but dealing with those is a hassle. Because the user should not have control over how things are named on your server, and because directories are irrelevant. If you want to make it look like there are directories then do that on the frontend - the actual URLs don't matter. Maybe.

Are you looking for help doing this yourself or are you looking to hire someone to do it for you?

Mostly. Let people upload images to a public location as long as access is supposed to be unrestricted and you do a good job verifying that the files are indeed images. If you wanted to allow all sorts of file types then this conversation would be going a different way and you'd need to consider making them private after all. Some people will say you should do it anyways. Me, not so much, because it's easy to verify that a file is an image and to ensure that it is only ever considered to be an image. The alternative is to not do that - to make them private and accessible through a script. And there are non-security benefits to that, like making it easier to count views, and full customization of the URL (with rewriting). You might as well consider whether you want to do that, but if you don't now and change your mind then you can use URL rewriting in the future to make it happen pretty easily. As for the user creating folders and specifying exact file names? No. You need to retain 100% control over exactly what each file is named and where it is placed on your server. You can incorporate the original name into the name you use, if you want, and for an image hosting thing that would probably be a good idea, but ultimately your code decides what to do. But you know, if you want to stop thinking about this, just go with the private thing. It's not wrong to do it. You have to worry about MIME types and file caching and partial responses, but those are solved problems.

But you want people to see the image. It's supposed to be easily accessible. That said, people should not be able to dictate filenames on your server, so generating your own name for them is still a good thing. It doesn't really matter where the images are. Consider the avatars on this forum: mine is /uploads/monthly_2021_02/catra.thumb.png.4c523d979ea05f55c35f4277018effe8.png. The only thing that shows is the upload date (nobody cares) and original filename (arguably useful information). It's fine.