How to prevent a PHP file called in action form to appear as a page ?

[nicoled94356575]

With this line <form name="myForm" id="myForm" action="manageMySQLGuests.php" method="post"> I cannot avoid manageMySQLGuests.php to appear as a page whilst only  CRUD transactions with MySQL occur in this PHP file (so that nothing needs to appear as I manage failures in another way).

[osgood_]

Youre not giving us enough information to provide you with an answer. If you dont have any client side validation on the form it will just go through to the manageMySQLGuests.php file.

The post has been marked as correct for some reason. If it wasnt you who marked the post as correct then it shouldnt have been but then again its a habit of someone going through the posts guessing at the correct answers, some which have been marked as correct are plainly incorrect or not the best answer provided.

Please only mark the answer as correct IF you are positive that the provided answer IS correct!

[nicoled94356575]

It's me who marked the question as answered but by error, I realized it but it was not possible to change back the status. The answer was correct as the PHP file that contains only background process did no longer appear on an new page on a new tab but did not solved completely the problem in that the page referring the PHP file is still refreshing when the form is submitted ( by the instruction outside of the form myForm = document.getElementById('myForm"); form.submit(); )

If someone is able to do it, unmarked this question as "assumed answered".

[osgood_]

I assume that you are validating the form input fields using javascript?

If you don't want the 'manageMySQLGuests.php file' to be activated UNTIL all the necessary information has been provided by the user then you would need to use:

return false;

if the javascript code encounters a vaildation error. That will stop the script running any further.

[nicoled94356575]

I used already JavaScript functions to validate form’s input fields at the presentation layer. Nothing prevents me to validate and make calculations in the business layer, and even if necessary, at the data layer with triggers. I have only a HTML / Javascript presentation layer and a PHP Data layer to interact with MySQL. At this stage, it is enough because I am discovering too many technologies at the same time in web developing (that is not my brilliance) to afford managing the complication induced by an intermediate business layer (at this stage at least). So, I replace all CRUD actions triggered by buttons (in a section outside the form) without submitting the form by ajax function working only in background and avoid in this way form’s refresh which are not desirable and disrupt all the mechanism. In others words, I have replaced the implicit POST from the post method of the form by ajax $.post for all fields of this form in functions defined for each CRUD action, and it works perfectly, transparently.

Thanks to Ajax, I made a giant step which will be engraved in gilt lettering in the mythology of Stackoverflow, DW CC Adobe Forum…  

[osgood_]

If you remove the post method from the form then you are not validating on the server side but only the client side via ajax which is unsecure, especially if you are updating a database.

[nicoled94356575]

False. I validate the form's fields with JavaScript functions before using Ajax to post their values.

[osgood_]

Ajax is javascript and you still have a url to the form proccesing script in the call to ajax. If someone was malicious they could easily take that url and put it back into the form.......and start messing with your data.

If the form is in a protected area for admins to use l wouldnt worry too much because admins are unlikely to want to mess the data up but if the form is open to members of the public  l would think about protecting the information it can send with server side scripting as back up security.

[nicoled94356575]

The mechanism seems to be clearer with ajax $.post than with POST of all fields values directly from the form.  It appears to me that it is much more difficult to deal with submit type button and/or with action= “file.php”. I tried many combinations as moving the buttons outside the form, and onclick= “form.submit(1..4)” as there are for CRUD actions. This previous solution worked but in an unpredictable sequence, as refreshing the form when it wasn’t necessary and so forth.

You are speaking about the need not to rely on the presentation layer (html page and form as a part of it) and to implement validation mechanisms at the data layer either in the php file (where should be the validation and calculation of the business layer) or in MySQL itself. Very well! But, it is a matter of good practices of which I am aware since I've been working with Oracle and SQL Server for over two decades, and in the most sensitive R&D fields as pharmaceutical data management. Very well too! But I had not to worry about web exchange between client side and often unpredictable servers’ side. You speak of security, protection principles. Could you clarify where is the flaw in addressing the server via Ajax which was designed for this especially in JavaScript obviously but with a specific syntax? I recall that you mentioned an URL to use Ajax. Where is the flaw in this? I can guess but, even if a DW CC forum should be dedicated to DW CC specificities and not general web programming issues, Il would like something a scheme depicting the flaw in the mechanism. I would like something as a scheme depicting the flaw in the mechanism or at least a link to an article pointing out the flank on which the attack could occur.

In addition, the mechanisms of the triggers of the Oracle interfaces such as SQL forms, forms 4.5 etc. were much better sequenced and clear than those that can be implemented on a Web page, especially when one is not yet a master of art. To develop a multi-level Master to Detail relationship as in an Oracle interface I must reinvent the wheel as I did it when I had to design a new audiology software with VB6 (this precision does not matter more than if I was talking about the sorting of beets that people have in their ears).

[osgood_]

nicoled94356575  wrote

I recall that you mentioned an URL to use Ajax. Where is the flaw in this?

Its accessible by anyone by just looking at the pages source code. Once someone malicious has the url they can use it to inject the form with the post attribute, turn off javascript, and potentailly wipe out the information in your database.

Do you have form validation in the manageMySQLGuests.php file or just the CRUD code for updating the database?

[nicoled94356575]

No validation yet in the php file and only the CRUD code in it as MySQL queries. Only a lot of constraints. A this level at least, it is armored

[nicoled94356575]

And I would add  osgood_ that I don't see any url when run this code:

<script type="text/javascript">

function insertActionCRUD( actionCRUD ) {

var bool = true;

var data = {

actionCRUD: actionCRUD

};

$.post( "actionCRUD.php", data );

return bool;

}

</script>

[osgood_]

nicoled94356575  wrote

And I would add  osgood_  that I don't see any url when run this code:

<script type="text/javascript">

function insertActionCRUD( actionCRUD ) {

var bool = true;

var data = {

actionCRUD: actionCRUD

};

$.post( "actionCRUD.php", data );

return bool;

}

</script>

You dont see any url in that bit of javascript code that is client-side...............?

Is this not the url to your processing script?

actionCRUD.php

Someone only needs to take that and inject into your form:

action="http://www.yourWebsiteAddress/actionCrud.php" method="post"

[nicoled94356575]

Sure. But by "don't see an URL", I meant something appearing on the top of the windows , what happens when you call a page with parameter as "file.php?id=..."How to refer to a php file from client side without the code being visible by simply clicking view source?

[osgood_]

nicoled94356575  wrote

How to refer to a php file from client side without the code being visible by simply clicking view source?

You cant, I don't think, that's why you also should include form validation in the php file if you want to be safe when dealing with databases which are 'open' and not hidden behind an admin section.

If might help if you are at least using either prepared statements in the php file or using real_escape_string to remove any characters that an attacker might use.

$name= $conn->real_escape_string($name);

Not sure if you are using any of that kind of workflow.

[BenPleysier]

As @osgood_ has pointed out, JavaScript, in whatever form you want to shape it, is a client-side scripting language, meaning that it is processed by the browser. As such it is accessible to anyone and everyone willing to deform it  for malicious purposes.

Server-side scripts, on the other hand, are hidden and not accessible to anyone making for a secure environment that cannot be interfered with.

Form validation using Ajax combines the logic of JavaScript and server-side script to achieve fast responsive results. Initially these results will rely on client-side validation and ultimately on server-side validation.

Why both forms of validation? Realtime feedback from client-side validation; secured feedback in case anyone wants to by-pass the client-side validation.

In other words, server-side validation is a must, client-side validation is a luxury.