PHP santization of textarea inputA take on DB Abstraction - PHP / MySqlPHP-Mysqli example secure?Inline PHP IP access logSanitzing input on form submit with PHPPHP MySQLi database wrapperThree PHP database queries to manage accountsPHP MySQLI Wrapper - SqlObjectLoading CSV into MySQL using OOP PHPusing $_POST array to prepare PDO statement with variablesSimple wrapper for PHP mysqli connection
Efficiently pathfinding many flocking enemies around obstacles
Is it safe to remove the bottom chords of a series of garage roof trusses?
Why does trim() NOT remove char 160?
Is "The life is beautiful" incorrect or just very non-idiomatic?
Why does The Ancient One think differently about Doctor Strange in Endgame than the film Doctor Strange?
Is there a known non-euclidean geometry where two concentric circles of different radii can intersect? (as in the novel "The Universe Between")
Is it possible to get crispy, crunchy carrots from canned carrots?
Would this system work to purify water?
Why different interest rates for checking and savings?
Who was president?
Algorithms vs LP or MIP
Are there account age or level requirements for obtaining special research?
Does travel insurance for short flight delays exist?
Can I double-dip a flight and claim it for both United and Lufthansa status miles?
Confirming resignation after resignation letter ripped up
What is this symbol: semicircles facing eachother
Why is Boris Johnson visiting only Paris & Berlin if every member of the EU needs to agree on a withdrawal deal?
Why is less being run unnecessarily by git?
Average period of peer review process
LeetCode: Pascal's Triangle C#
What is the history of the university asylum law?
Why were the crew so desperate to catch Truman and return him to Seahaven?
How to respectfully refuse to assist co-workers with IT issues?
Which household object drew this pattern?
PHP santization of textarea input
A take on DB Abstraction - PHP / MySqlPHP-Mysqli example secure?Inline PHP IP access logSanitzing input on form submit with PHPPHP MySQLi database wrapperThree PHP database queries to manage accountsPHP MySQLI Wrapper - SqlObjectLoading CSV into MySQL using OOP PHPusing $_POST array to prepare PDO statement with variablesSimple wrapper for PHP mysqli connection
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
$begingroup$
My application will accept textarea content that is submitted by a user, and i would like some people to review my code to make sure there is no security vulnerability such as XSS.
My mySQL column that will save this information is a column of type TEXT
and is not required and nullable.
When storing the data to database, my script is doing the following:
// to avoid inserting html tags in the database
$input = str_replace(["<", ">"],"", $_POST['userinput'])
// to avoid saving problematic characters such as quotes
$cleanInput = htmlentities(input , ENT_QUOTES)
// store the content
$addPostStmt = $conn -> prepare("
INSERT INTO posts(description) VALUES ( ?)
");
$addPostStmt -> bind_param("s", $cleanInput);
$addPostStmtExecute = $addPostStmt -> execute();
When presenting the data to the user, the script is doing the following:
<?php echo htmlspecialchars(html_entity_decode($post['description']), ENT_SUBSTITUTE); ?>
php mysql mysqli escaping
$endgroup$
add a comment |
$begingroup$
My application will accept textarea content that is submitted by a user, and i would like some people to review my code to make sure there is no security vulnerability such as XSS.
My mySQL column that will save this information is a column of type TEXT
and is not required and nullable.
When storing the data to database, my script is doing the following:
// to avoid inserting html tags in the database
$input = str_replace(["<", ">"],"", $_POST['userinput'])
// to avoid saving problematic characters such as quotes
$cleanInput = htmlentities(input , ENT_QUOTES)
// store the content
$addPostStmt = $conn -> prepare("
INSERT INTO posts(description) VALUES ( ?)
");
$addPostStmt -> bind_param("s", $cleanInput);
$addPostStmtExecute = $addPostStmt -> execute();
When presenting the data to the user, the script is doing the following:
<?php echo htmlspecialchars(html_entity_decode($post['description']), ENT_SUBSTITUTE); ?>
php mysql mysqli escaping
$endgroup$
$begingroup$
What's the logic behind doing htmlspecialchars/ html_entity_decode/ then htmlspecialchars again?
$endgroup$
– Your Common Sense
Aug 10 at 16:43
$begingroup$
@YourCommonSense not sure what you mean by htmlspecialchars again, i am only doing it one, after decoding the html entities. its mostly incase something slips through
$endgroup$
– pabloBar
Aug 10 at 16:55
$begingroup$
htmlspecialchars and htmlentities is virtually the same, so what's the point doing the same job twice?
$endgroup$
– Your Common Sense
Aug 10 at 17:00
$begingroup$
Or to put it the other way, what's the point in doing entity encode and then decode?
$endgroup$
– Your Common Sense
Aug 10 at 17:02
add a comment |
$begingroup$
My application will accept textarea content that is submitted by a user, and i would like some people to review my code to make sure there is no security vulnerability such as XSS.
My mySQL column that will save this information is a column of type TEXT
and is not required and nullable.
When storing the data to database, my script is doing the following:
// to avoid inserting html tags in the database
$input = str_replace(["<", ">"],"", $_POST['userinput'])
// to avoid saving problematic characters such as quotes
$cleanInput = htmlentities(input , ENT_QUOTES)
// store the content
$addPostStmt = $conn -> prepare("
INSERT INTO posts(description) VALUES ( ?)
");
$addPostStmt -> bind_param("s", $cleanInput);
$addPostStmtExecute = $addPostStmt -> execute();
When presenting the data to the user, the script is doing the following:
<?php echo htmlspecialchars(html_entity_decode($post['description']), ENT_SUBSTITUTE); ?>
php mysql mysqli escaping
$endgroup$
My application will accept textarea content that is submitted by a user, and i would like some people to review my code to make sure there is no security vulnerability such as XSS.
My mySQL column that will save this information is a column of type TEXT
and is not required and nullable.
When storing the data to database, my script is doing the following:
// to avoid inserting html tags in the database
$input = str_replace(["<", ">"],"", $_POST['userinput'])
// to avoid saving problematic characters such as quotes
$cleanInput = htmlentities(input , ENT_QUOTES)
// store the content
$addPostStmt = $conn -> prepare("
INSERT INTO posts(description) VALUES ( ?)
");
$addPostStmt -> bind_param("s", $cleanInput);
$addPostStmtExecute = $addPostStmt -> execute();
When presenting the data to the user, the script is doing the following:
<?php echo htmlspecialchars(html_entity_decode($post['description']), ENT_SUBSTITUTE); ?>
php mysql mysqli escaping
php mysql mysqli escaping
edited Aug 10 at 16:41
200_success
135k21 gold badges173 silver badges443 bronze badges
135k21 gold badges173 silver badges443 bronze badges
asked Aug 10 at 16:35
pabloBarpabloBar
334 bronze badges
334 bronze badges
$begingroup$
What's the logic behind doing htmlspecialchars/ html_entity_decode/ then htmlspecialchars again?
$endgroup$
– Your Common Sense
Aug 10 at 16:43
$begingroup$
@YourCommonSense not sure what you mean by htmlspecialchars again, i am only doing it one, after decoding the html entities. its mostly incase something slips through
$endgroup$
– pabloBar
Aug 10 at 16:55
$begingroup$
htmlspecialchars and htmlentities is virtually the same, so what's the point doing the same job twice?
$endgroup$
– Your Common Sense
Aug 10 at 17:00
$begingroup$
Or to put it the other way, what's the point in doing entity encode and then decode?
$endgroup$
– Your Common Sense
Aug 10 at 17:02
add a comment |
$begingroup$
What's the logic behind doing htmlspecialchars/ html_entity_decode/ then htmlspecialchars again?
$endgroup$
– Your Common Sense
Aug 10 at 16:43
$begingroup$
@YourCommonSense not sure what you mean by htmlspecialchars again, i am only doing it one, after decoding the html entities. its mostly incase something slips through
$endgroup$
– pabloBar
Aug 10 at 16:55
$begingroup$
htmlspecialchars and htmlentities is virtually the same, so what's the point doing the same job twice?
$endgroup$
– Your Common Sense
Aug 10 at 17:00
$begingroup$
Or to put it the other way, what's the point in doing entity encode and then decode?
$endgroup$
– Your Common Sense
Aug 10 at 17:02
$begingroup$
What's the logic behind doing htmlspecialchars/ html_entity_decode/ then htmlspecialchars again?
$endgroup$
– Your Common Sense
Aug 10 at 16:43
$begingroup$
What's the logic behind doing htmlspecialchars/ html_entity_decode/ then htmlspecialchars again?
$endgroup$
– Your Common Sense
Aug 10 at 16:43
$begingroup$
@YourCommonSense not sure what you mean by htmlspecialchars again, i am only doing it one, after decoding the html entities. its mostly incase something slips through
$endgroup$
– pabloBar
Aug 10 at 16:55
$begingroup$
@YourCommonSense not sure what you mean by htmlspecialchars again, i am only doing it one, after decoding the html entities. its mostly incase something slips through
$endgroup$
– pabloBar
Aug 10 at 16:55
$begingroup$
htmlspecialchars and htmlentities is virtually the same, so what's the point doing the same job twice?
$endgroup$
– Your Common Sense
Aug 10 at 17:00
$begingroup$
htmlspecialchars and htmlentities is virtually the same, so what's the point doing the same job twice?
$endgroup$
– Your Common Sense
Aug 10 at 17:00
$begingroup$
Or to put it the other way, what's the point in doing entity encode and then decode?
$endgroup$
– Your Common Sense
Aug 10 at 17:02
$begingroup$
Or to put it the other way, what's the point in doing entity encode and then decode?
$endgroup$
– Your Common Sense
Aug 10 at 17:02
add a comment |
1 Answer
1
active
oldest
votes
$begingroup$
No, don't do that. You seem to be filtering and escaping values out of paranoia rather than understanding what exactly would lead to a vulnerability. As a result, you are corrupting your data.
A well designed application should use the database to store the value that the user typed into the textarea, not some mangled representation of it. If you mangle the data like that before storing it, then:
- Certain characters that the user typed get dropped. (What if the user input is
x + 3 < 5
? The data would no longer make sense after you drop the<
character.) - Your database is not reliably searchable. (What if the user input is
She said "yes!"
? Then you would store a value in the database with"
in it.) - If you arbitrarily apply escaping to string just in case, then you'll have a hard time keeping track of how to unescape it correctly when regurgitating the data. (This often leads to bugs where the user sees garbage like
his & hers
, or even worse,his &amp; hers
.)
What's the right way? Don't mangle the data; just store it faithfully:
// store the content
$addPostStmt = $conn -> prepare("
INSERT INTO posts(description) VALUES (?)
");
$addPostStmt -> bind_param("s", $_POST['userinput']);
$addPostStmtExecute = $addPostStmt -> execute();
When outputting the data as HTML, apply HTML escaping:
<th>Description:</th><td><?php echo htmlspecialchars($description); ?></td>
$endgroup$
$begingroup$
escaping values out of paranoia, that is correct tbh. As i dont have a alot of experience with php and mysql, i chose to be very careful to what to add to my database. 1.<
and>
does not get used usually when writing content like articles and description. So i thought it would be safer to remove it. The content wont be related to math but i see your point. But instead of filtering out these character, is ok to filter<script
instead in case someday i forgot to usehtmlspecialchars
$endgroup$
– pabloBar
Aug 10 at 21:35
$begingroup$
2. and 3. True and i completely agree, but the reason i chose to do it like that is because i was not really certain if there where any magical/non-visible character that might cause a problem with sql. But as long i am using prepared statments i guess i should be fine. Are there edge case scenarios that i should be aware of, where having quote characters in the database might be dangerous?
$endgroup$
– pabloBar
Aug 10 at 21:36
2
$begingroup$
Nothing more to worry about. You're using the database API correctly. Just trust that it does the right thing, and don't apply any extra data-corrupting transformations. As long you callhtmlspecialchars()
when outputting the string as HTML, that will correctly take care of XSS concerns.
$endgroup$
– 200_success
Aug 10 at 23:06
$begingroup$
just a side question, why did you drop theENT_SUBSTITUTE
flag ?
$endgroup$
– pabloBar
Aug 11 at 20:30
$begingroup$
Becausehtml_entity_decode()
should be unnecessary altogether, if you don't apply a superfluous round of encoding withhtmlentities()
.
$endgroup$
– 200_success
Aug 12 at 2:00
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "196"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f225894%2fphp-santization-of-textarea-input%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
$begingroup$
No, don't do that. You seem to be filtering and escaping values out of paranoia rather than understanding what exactly would lead to a vulnerability. As a result, you are corrupting your data.
A well designed application should use the database to store the value that the user typed into the textarea, not some mangled representation of it. If you mangle the data like that before storing it, then:
- Certain characters that the user typed get dropped. (What if the user input is
x + 3 < 5
? The data would no longer make sense after you drop the<
character.) - Your database is not reliably searchable. (What if the user input is
She said "yes!"
? Then you would store a value in the database with"
in it.) - If you arbitrarily apply escaping to string just in case, then you'll have a hard time keeping track of how to unescape it correctly when regurgitating the data. (This often leads to bugs where the user sees garbage like
his & hers
, or even worse,his &amp; hers
.)
What's the right way? Don't mangle the data; just store it faithfully:
// store the content
$addPostStmt = $conn -> prepare("
INSERT INTO posts(description) VALUES (?)
");
$addPostStmt -> bind_param("s", $_POST['userinput']);
$addPostStmtExecute = $addPostStmt -> execute();
When outputting the data as HTML, apply HTML escaping:
<th>Description:</th><td><?php echo htmlspecialchars($description); ?></td>
$endgroup$
$begingroup$
escaping values out of paranoia, that is correct tbh. As i dont have a alot of experience with php and mysql, i chose to be very careful to what to add to my database. 1.<
and>
does not get used usually when writing content like articles and description. So i thought it would be safer to remove it. The content wont be related to math but i see your point. But instead of filtering out these character, is ok to filter<script
instead in case someday i forgot to usehtmlspecialchars
$endgroup$
– pabloBar
Aug 10 at 21:35
$begingroup$
2. and 3. True and i completely agree, but the reason i chose to do it like that is because i was not really certain if there where any magical/non-visible character that might cause a problem with sql. But as long i am using prepared statments i guess i should be fine. Are there edge case scenarios that i should be aware of, where having quote characters in the database might be dangerous?
$endgroup$
– pabloBar
Aug 10 at 21:36
2
$begingroup$
Nothing more to worry about. You're using the database API correctly. Just trust that it does the right thing, and don't apply any extra data-corrupting transformations. As long you callhtmlspecialchars()
when outputting the string as HTML, that will correctly take care of XSS concerns.
$endgroup$
– 200_success
Aug 10 at 23:06
$begingroup$
just a side question, why did you drop theENT_SUBSTITUTE
flag ?
$endgroup$
– pabloBar
Aug 11 at 20:30
$begingroup$
Becausehtml_entity_decode()
should be unnecessary altogether, if you don't apply a superfluous round of encoding withhtmlentities()
.
$endgroup$
– 200_success
Aug 12 at 2:00
add a comment |
$begingroup$
No, don't do that. You seem to be filtering and escaping values out of paranoia rather than understanding what exactly would lead to a vulnerability. As a result, you are corrupting your data.
A well designed application should use the database to store the value that the user typed into the textarea, not some mangled representation of it. If you mangle the data like that before storing it, then:
- Certain characters that the user typed get dropped. (What if the user input is
x + 3 < 5
? The data would no longer make sense after you drop the<
character.) - Your database is not reliably searchable. (What if the user input is
She said "yes!"
? Then you would store a value in the database with"
in it.) - If you arbitrarily apply escaping to string just in case, then you'll have a hard time keeping track of how to unescape it correctly when regurgitating the data. (This often leads to bugs where the user sees garbage like
his & hers
, or even worse,his &amp; hers
.)
What's the right way? Don't mangle the data; just store it faithfully:
// store the content
$addPostStmt = $conn -> prepare("
INSERT INTO posts(description) VALUES (?)
");
$addPostStmt -> bind_param("s", $_POST['userinput']);
$addPostStmtExecute = $addPostStmt -> execute();
When outputting the data as HTML, apply HTML escaping:
<th>Description:</th><td><?php echo htmlspecialchars($description); ?></td>
$endgroup$
$begingroup$
escaping values out of paranoia, that is correct tbh. As i dont have a alot of experience with php and mysql, i chose to be very careful to what to add to my database. 1.<
and>
does not get used usually when writing content like articles and description. So i thought it would be safer to remove it. The content wont be related to math but i see your point. But instead of filtering out these character, is ok to filter<script
instead in case someday i forgot to usehtmlspecialchars
$endgroup$
– pabloBar
Aug 10 at 21:35
$begingroup$
2. and 3. True and i completely agree, but the reason i chose to do it like that is because i was not really certain if there where any magical/non-visible character that might cause a problem with sql. But as long i am using prepared statments i guess i should be fine. Are there edge case scenarios that i should be aware of, where having quote characters in the database might be dangerous?
$endgroup$
– pabloBar
Aug 10 at 21:36
2
$begingroup$
Nothing more to worry about. You're using the database API correctly. Just trust that it does the right thing, and don't apply any extra data-corrupting transformations. As long you callhtmlspecialchars()
when outputting the string as HTML, that will correctly take care of XSS concerns.
$endgroup$
– 200_success
Aug 10 at 23:06
$begingroup$
just a side question, why did you drop theENT_SUBSTITUTE
flag ?
$endgroup$
– pabloBar
Aug 11 at 20:30
$begingroup$
Becausehtml_entity_decode()
should be unnecessary altogether, if you don't apply a superfluous round of encoding withhtmlentities()
.
$endgroup$
– 200_success
Aug 12 at 2:00
add a comment |
$begingroup$
No, don't do that. You seem to be filtering and escaping values out of paranoia rather than understanding what exactly would lead to a vulnerability. As a result, you are corrupting your data.
A well designed application should use the database to store the value that the user typed into the textarea, not some mangled representation of it. If you mangle the data like that before storing it, then:
- Certain characters that the user typed get dropped. (What if the user input is
x + 3 < 5
? The data would no longer make sense after you drop the<
character.) - Your database is not reliably searchable. (What if the user input is
She said "yes!"
? Then you would store a value in the database with"
in it.) - If you arbitrarily apply escaping to string just in case, then you'll have a hard time keeping track of how to unescape it correctly when regurgitating the data. (This often leads to bugs where the user sees garbage like
his & hers
, or even worse,his &amp; hers
.)
What's the right way? Don't mangle the data; just store it faithfully:
// store the content
$addPostStmt = $conn -> prepare("
INSERT INTO posts(description) VALUES (?)
");
$addPostStmt -> bind_param("s", $_POST['userinput']);
$addPostStmtExecute = $addPostStmt -> execute();
When outputting the data as HTML, apply HTML escaping:
<th>Description:</th><td><?php echo htmlspecialchars($description); ?></td>
$endgroup$
No, don't do that. You seem to be filtering and escaping values out of paranoia rather than understanding what exactly would lead to a vulnerability. As a result, you are corrupting your data.
A well designed application should use the database to store the value that the user typed into the textarea, not some mangled representation of it. If you mangle the data like that before storing it, then:
- Certain characters that the user typed get dropped. (What if the user input is
x + 3 < 5
? The data would no longer make sense after you drop the<
character.) - Your database is not reliably searchable. (What if the user input is
She said "yes!"
? Then you would store a value in the database with"
in it.) - If you arbitrarily apply escaping to string just in case, then you'll have a hard time keeping track of how to unescape it correctly when regurgitating the data. (This often leads to bugs where the user sees garbage like
his & hers
, or even worse,his &amp; hers
.)
What's the right way? Don't mangle the data; just store it faithfully:
// store the content
$addPostStmt = $conn -> prepare("
INSERT INTO posts(description) VALUES (?)
");
$addPostStmt -> bind_param("s", $_POST['userinput']);
$addPostStmtExecute = $addPostStmt -> execute();
When outputting the data as HTML, apply HTML escaping:
<th>Description:</th><td><?php echo htmlspecialchars($description); ?></td>
edited Aug 10 at 23:06
answered Aug 10 at 17:05
200_success200_success
135k21 gold badges173 silver badges443 bronze badges
135k21 gold badges173 silver badges443 bronze badges
$begingroup$
escaping values out of paranoia, that is correct tbh. As i dont have a alot of experience with php and mysql, i chose to be very careful to what to add to my database. 1.<
and>
does not get used usually when writing content like articles and description. So i thought it would be safer to remove it. The content wont be related to math but i see your point. But instead of filtering out these character, is ok to filter<script
instead in case someday i forgot to usehtmlspecialchars
$endgroup$
– pabloBar
Aug 10 at 21:35
$begingroup$
2. and 3. True and i completely agree, but the reason i chose to do it like that is because i was not really certain if there where any magical/non-visible character that might cause a problem with sql. But as long i am using prepared statments i guess i should be fine. Are there edge case scenarios that i should be aware of, where having quote characters in the database might be dangerous?
$endgroup$
– pabloBar
Aug 10 at 21:36
2
$begingroup$
Nothing more to worry about. You're using the database API correctly. Just trust that it does the right thing, and don't apply any extra data-corrupting transformations. As long you callhtmlspecialchars()
when outputting the string as HTML, that will correctly take care of XSS concerns.
$endgroup$
– 200_success
Aug 10 at 23:06
$begingroup$
just a side question, why did you drop theENT_SUBSTITUTE
flag ?
$endgroup$
– pabloBar
Aug 11 at 20:30
$begingroup$
Becausehtml_entity_decode()
should be unnecessary altogether, if you don't apply a superfluous round of encoding withhtmlentities()
.
$endgroup$
– 200_success
Aug 12 at 2:00
add a comment |
$begingroup$
escaping values out of paranoia, that is correct tbh. As i dont have a alot of experience with php and mysql, i chose to be very careful to what to add to my database. 1.<
and>
does not get used usually when writing content like articles and description. So i thought it would be safer to remove it. The content wont be related to math but i see your point. But instead of filtering out these character, is ok to filter<script
instead in case someday i forgot to usehtmlspecialchars
$endgroup$
– pabloBar
Aug 10 at 21:35
$begingroup$
2. and 3. True and i completely agree, but the reason i chose to do it like that is because i was not really certain if there where any magical/non-visible character that might cause a problem with sql. But as long i am using prepared statments i guess i should be fine. Are there edge case scenarios that i should be aware of, where having quote characters in the database might be dangerous?
$endgroup$
– pabloBar
Aug 10 at 21:36
2
$begingroup$
Nothing more to worry about. You're using the database API correctly. Just trust that it does the right thing, and don't apply any extra data-corrupting transformations. As long you callhtmlspecialchars()
when outputting the string as HTML, that will correctly take care of XSS concerns.
$endgroup$
– 200_success
Aug 10 at 23:06
$begingroup$
just a side question, why did you drop theENT_SUBSTITUTE
flag ?
$endgroup$
– pabloBar
Aug 11 at 20:30
$begingroup$
Becausehtml_entity_decode()
should be unnecessary altogether, if you don't apply a superfluous round of encoding withhtmlentities()
.
$endgroup$
– 200_success
Aug 12 at 2:00
$begingroup$
escaping values out of paranoia, that is correct tbh. As i dont have a alot of experience with php and mysql, i chose to be very careful to what to add to my database. 1.
<
and >
does not get used usually when writing content like articles and description. So i thought it would be safer to remove it. The content wont be related to math but i see your point. But instead of filtering out these character, is ok to filter <script
instead in case someday i forgot to use htmlspecialchars
$endgroup$
– pabloBar
Aug 10 at 21:35
$begingroup$
escaping values out of paranoia, that is correct tbh. As i dont have a alot of experience with php and mysql, i chose to be very careful to what to add to my database. 1.
<
and >
does not get used usually when writing content like articles and description. So i thought it would be safer to remove it. The content wont be related to math but i see your point. But instead of filtering out these character, is ok to filter <script
instead in case someday i forgot to use htmlspecialchars
$endgroup$
– pabloBar
Aug 10 at 21:35
$begingroup$
2. and 3. True and i completely agree, but the reason i chose to do it like that is because i was not really certain if there where any magical/non-visible character that might cause a problem with sql. But as long i am using prepared statments i guess i should be fine. Are there edge case scenarios that i should be aware of, where having quote characters in the database might be dangerous?
$endgroup$
– pabloBar
Aug 10 at 21:36
$begingroup$
2. and 3. True and i completely agree, but the reason i chose to do it like that is because i was not really certain if there where any magical/non-visible character that might cause a problem with sql. But as long i am using prepared statments i guess i should be fine. Are there edge case scenarios that i should be aware of, where having quote characters in the database might be dangerous?
$endgroup$
– pabloBar
Aug 10 at 21:36
2
2
$begingroup$
Nothing more to worry about. You're using the database API correctly. Just trust that it does the right thing, and don't apply any extra data-corrupting transformations. As long you call
htmlspecialchars()
when outputting the string as HTML, that will correctly take care of XSS concerns.$endgroup$
– 200_success
Aug 10 at 23:06
$begingroup$
Nothing more to worry about. You're using the database API correctly. Just trust that it does the right thing, and don't apply any extra data-corrupting transformations. As long you call
htmlspecialchars()
when outputting the string as HTML, that will correctly take care of XSS concerns.$endgroup$
– 200_success
Aug 10 at 23:06
$begingroup$
just a side question, why did you drop the
ENT_SUBSTITUTE
flag ?$endgroup$
– pabloBar
Aug 11 at 20:30
$begingroup$
just a side question, why did you drop the
ENT_SUBSTITUTE
flag ?$endgroup$
– pabloBar
Aug 11 at 20:30
$begingroup$
Because
html_entity_decode()
should be unnecessary altogether, if you don't apply a superfluous round of encoding with htmlentities()
.$endgroup$
– 200_success
Aug 12 at 2:00
$begingroup$
Because
html_entity_decode()
should be unnecessary altogether, if you don't apply a superfluous round of encoding with htmlentities()
.$endgroup$
– 200_success
Aug 12 at 2:00
add a comment |
Thanks for contributing an answer to Code Review Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f225894%2fphp-santization-of-textarea-input%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
$begingroup$
What's the logic behind doing htmlspecialchars/ html_entity_decode/ then htmlspecialchars again?
$endgroup$
– Your Common Sense
Aug 10 at 16:43
$begingroup$
@YourCommonSense not sure what you mean by htmlspecialchars again, i am only doing it one, after decoding the html entities. its mostly incase something slips through
$endgroup$
– pabloBar
Aug 10 at 16:55
$begingroup$
htmlspecialchars and htmlentities is virtually the same, so what's the point doing the same job twice?
$endgroup$
– Your Common Sense
Aug 10 at 17:00
$begingroup$
Or to put it the other way, what's the point in doing entity encode and then decode?
$endgroup$
– Your Common Sense
Aug 10 at 17:02