Mdthbs

Was this a rapid SCHEDULED disassembly? How was it done?

English - Acceptable use of parentheses in an author's name

Performance of a branch and bound algorithm VS branch-cut-heuristics

Is TA-ing worth the opportunity cost?

First amendment and employment: Can an employer terminate you for speech?

PHP santization of textarea input

Does this Foo machine halt?

As a 16 year old, how can I keep my money safe from my mother?

Best gun to modify into a monsterhunter weapon?

During the Space Shuttle Columbia Disaster of 2003, Why Did The Flight Director Say, "Lock the doors."?

sed delete all the words before a match

Unique combinations of a list of tuples

How can I iterate this process?

Why aren’t emergency services using callsigns?

Why level 0 espers are considered espers if they have no powers at all?

Why isn’t SHA-3 in wider use?

Acceptable to cut steak before searing?

Why are the inside diameters of some pipe larger than the stated size?

Why is there a need to prevent a racist, sexist, or otherwise bigoted vendor from discriminating who they sell to?

A stranger from Norway wants to have money delivered to me

How do I explain to a team that the project they will work on for six months will certainly be cancelled?

How should an administrative assistant reply to student addressing them as "Professor" or "Doctor"?

Strangeness with gears

Why should we care about syntactic proofs if we can show semantically that statements are true?

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;
}

1

$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

share|improve this question

edited 9 hours ago

200_success

135k2121 gold badges173173 silver badges443443 bronze badges

asked 9 hours ago

pabloBarpabloBar

2844 bronze badges

$endgroup$

• 
  
  
  

  
  

  
  
  
  
  
  

  
  $begingroup$
  What's the logic behind doing htmlspecialchars/ html_entity_decode/ then htmlspecialchars again?
  $endgroup$
  – Your Common Sense
  9 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  $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
  9 hours ago
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  $begingroup$
  htmlspecialchars and htmlentities is virtually the same, so what's the point doing the same job twice?
  $endgroup$
  – Your Common Sense
  9 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  $begingroup$
  Or to put it the other way, what's the point in doing entity encode and then decode?
  $endgroup$
  – Your Common Sense
  9 hours ago
  

  
  
  
  

add a comment | 

1

$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

share|improve this question

edited 9 hours ago

200_success

135k2121 gold badges173173 silver badges443443 bronze badges

asked 9 hours ago

pabloBarpabloBar

2844 bronze badges

$endgroup$

• 
  
  
  

  
  

  
  
  
  
  
  

  
  $begingroup$
  What's the logic behind doing htmlspecialchars/ html_entity_decode/ then htmlspecialchars again?
  $endgroup$
  – Your Common Sense
  9 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  $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
  9 hours ago
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  $begingroup$
  htmlspecialchars and htmlentities is virtually the same, so what's the point doing the same job twice?
  $endgroup$
  – Your Common Sense
  9 hours ago
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  $begingroup$
  Or to put it the other way, what's the point in doing entity encode and then decode?
  $endgroup$
  – Your Common Sense
  9 hours ago
  

  
  
  
  

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

share|improve this question

edited 9 hours ago

200_success

135k2121 gold badges173173 silver badges443443 bronze badges

asked 9 hours ago

pabloBarpabloBar

2844 bronze badges

$endgroup$

// 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();

<?php echo htmlspecialchars(html_entity_decode($post['description']), ENT_SUBSTITUTE); ?>

share|improve this question

edited 9 hours ago

200_success

135k2121 gold badges173173 silver badges443443 bronze badges

asked 9 hours ago

pabloBarpabloBar

2844 bronze badges

share|improve this question

edited 9 hours ago

200_success

135k2121 gold badges173173 silver badges443443 bronze badges

asked 9 hours ago

pabloBarpabloBar

2844 bronze badges

edited 9 hours ago

200_success

135k2121 gold badges173173 silver badges443443 bronze badges

edited 9 hours ago

200_success

135k2121 gold badges173173 silver badges443443 bronze badges

asked 9 hours ago

pabloBarpabloBar

2844 bronze badges

asked 9 hours ago

pabloBarpabloBar

2844 bronze badges

1 Answer
1

active

oldest

votes

3

$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 & 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>

share|improve this answer

edited 3 hours ago

answered 9 hours ago

200_success200_success

135k2121 gold badges173173 silver badges443443 bronze badges

$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 use htmlspecialchars
  $endgroup$
  – pabloBar
  4 hours ago
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  $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
  4 hours ago
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  $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
  3 hours ago
  

  
  
  
  

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
});


}
});

draft saved

draft discarded

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

Name

Email

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

Name

Email

Required, but never shown

3

$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 & 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>

share|improve this answer

edited 3 hours ago

answered 9 hours ago

200_success200_success

135k2121 gold badges173173 silver badges443443 bronze badges

$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 use htmlspecialchars
  $endgroup$
  – pabloBar
  4 hours ago
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  $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
  4 hours ago
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  $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
  3 hours ago
  

  
  
  
  

add a comment | 

3

$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 & 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>

share|improve this answer

edited 3 hours ago

answered 9 hours ago

200_success200_success

135k2121 gold badges173173 silver badges443443 bronze badges

$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 use htmlspecialchars
  $endgroup$
  – pabloBar
  4 hours ago
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  $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
  4 hours ago
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  $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
  3 hours ago
  

  
  
  
  

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 & 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>

share|improve this answer

edited 3 hours ago

answered 9 hours ago

200_success200_success

135k2121 gold badges173173 silver badges443443 bronze badges

$endgroup$

// store the content

$addPostStmt = $conn -> prepare("

  INSERT INTO posts(description) VALUES (?)

");



$addPostStmt -> bind_param("s", $_POST['userinput']); 

$addPostStmtExecute = $addPostStmt -> execute();

<th>Description:</th><td><?php echo htmlspecialchars($description); ?></td>

share|improve this answer

edited 3 hours ago

answered 9 hours ago

200_success200_success

135k2121 gold badges173173 silver badges443443 bronze badges

answered 9 hours ago

200_success200_success

135k2121 gold badges173173 silver badges443443 bronze badges

answered 9 hours ago

200_success200_success

135k2121 gold badges173173 silver badges443443 bronze badges