Tag Info

New answers tagged

0

When do I escape the data? Basically, as late as possible. The database is somewhere to store data, it is not a place to encode (escape) data. Of course use parameterised prepared statements to prevent any SQL injection attacks, but that should be as far as you take it. Your goal for writing to the database is simply to store the data successfully and ...


1

You probably need to google and read about XSS but here's a quick intro. Cross-site scripting is an attack where a hostile site, let's call it H, attacks your site S. H has on it a link to S that has malicious code in it that has been designed to provide the attacker with some benefit (eg: useful information or perform an action). This will likely only work ...


0

Unless you are undergoing a polygraph examination (in which case you will have already disclosed pertinent answers such as 'have you hacked a system' and are merely being tested on truthfulness of your disclosures) then take the American attitude of anti-self incrimination (the 5th Amendment to the US Constitution). During your interview, simply explain ...


-1

you put user input directly into a DB?... Bad idea (in general). You should sanitize all Input. (so input coming from the client and input coming from the Database). You are relying on the Client to make values safe in your example. something you should never fully trust as its outside of your control. for the rest I defer to @SilverlightFox as his ...


2

There's no such thing as special characters. It all depends on the context that input is used within your application. Protecting against SQLi and XSS is great, however if then input is then to be used in an operating system shell call it does you no good. Always encode or sanitize when the data is used - leave this as late as possible. For example when ...


0

cant send a victim this link with the injected code This might be possible if you find that some input will populate the field. Try POST and GET requests for the page, and attempt to populate the field using either its name (if it has one), but also try id and other variations. Have a look at the rest of the application and see if there are any ...


3

This is not to prevent double quotes, single quotes or spaces from breaking out of the attribute context, as this is covered by "Aggressive HTML Entity Encoding". For background, an attack like this is possible: <body background="javascript:alert('XSS')"> For id and name, these attributes are frequently used as reference points in the DOM. If an ...


1

Yes, it can be bypassed. First, many filters that attempt to remove <script> tags do so in a way that is easily defeated. For example, they may improperly handle input like <scr<script>ipt>. But even when implemented "properly", that is not sufficient, because <script> tags are not required to execute Javascript on a page: event ...


0

The text is saying that you need to validate untrusted input when used as any attribute. It is just a restatement of rule 2. Characters such as " could cause big problems.


4

Avoiding attacks on your site You need to validate that the string you received is valid. Remember this principle: you must white-list acceptable strings rather than black-list unacceptable ones. Ensure that the string is a syntactically-correct and escaped URL. Escaping the whole URL avoids it containing " or > which could break your site's syntax. ...


0

Encoding / Decoding coupled with XSS sanitation pre save and pre dom render is best practice. Mitigation strategies regarding browser DOM XSS attacks vary but can be strengthened with header options found here (https://www.owasp.org/index.php/List_of_useful_HTTP_headers). While zero day vulnerabilities may exist in the various browser rendering engines ...


1

As @Gumbo has said, CRLF are properly encoded with %0d%0a in the resulting URL, as you may see. If it had set headers as you had passed as parameters, you would have seen those headers separately. You may try different encoding instead, like %E5%98%8A%E5%98%8D :) The ability of attacker to construct arbitrary HTTP responses permits a variety of resulting ...


4

According to your question Chrome was loading a plain HTTP favicon in a HTTPS page without any browser warning. Interesting. Redirecting to a plain HTTP website is not a vulnerability in itself. However, it is a security flaw if the redirect is accidental and you want your users to remain on a secure, trusted channel to your site. Script content will not ...


0

Redirection with Javascript or META tags ... You can not send a 301 status code via Javascript or META tags. Since the HTTP status code of the page will remain 200 OK ... ... Another disadvantage is that some browsers disable Javascript or META refresh. Therefore, one must include a link to the destination page in the body of the page ... URL redirection ...


1

There is indeed a vulnerability, because as you observed, an attacker could intercept the traffic on the unsecured line and change it. The reason your script didn't execute is that this came in the favicon, and Chrome (apparently) does not execute scripts in the favicon. To exploit this, you would have to get Chrome to execute the code in the favicion. ...


1

I suppose if the tracker is using HTML/javascript to show content then yes - it's possible. If there isn't any XSS protection in place, someone could include the following: myfile.txt<script>alert(1);</script> in a file name or some other field that is rendered and it could potentially execute.



Top 50 recent answers are included