Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>What was right in their description: variables like '<em>document.location</em>', '<em>window.location</em>', '<em>self.location</em>' are (partially) controlled by non-trusted user. This is because the choice of (sub)string in non-trusted domain and page location ('http://<strong>non.trusted.domain</strong>.com/<strong>mypage</strong>') and non-trusted request string ('http://my.domain.com/?<strong>myrequest</strong>') are formed according to user's intention that may not always be good for you.</p> <p>What was wrong: this user-dependency is not necessarily XSS vulnerability. In fact, to form XSS you would need to have some code that effectively <em>uses</em> the content controlled by non-trusted user somewhere in your output stream for your page. In the example of simple framekiller like <code>top.location.replace(window.location)</code> there's no danger of XSS.</p> <p>One example where we could talk about XSS would be code like</p> <p><code>document.write('&lt;a href="' + document.location + '?newvar=newvalue"&gt;Click here&lt;/a&gt;')</code></p> <p>Constructing URI like <code>http://test.com/?dummy"&lt;script&gt;alert("Test")&lt;/script&gt;"dummy</code> and substituting instead of <em>document.location</em> by you code will trigger non-trusted script in trusted webpage's context. As constructing such URI and passing it unescaped is a challenge, real XSS would work in some more complex scenarios involving inserting non-trusted variables verbatim into flow of language directives, be it HTML, CSS, JS, PHP, etc.</p> <p>Another well-known example of XSS-unaware development was history of inventing <a href="http://www.json.org" rel="nofollow">JSON</a>. While JSON has got strong popularity (having me among its proponents too), initially it was intended as "quick-n-dirty" way of storing JS data as pieces of plain JS-formatted data structures. In order to "parse" JSON blocks, it was enough just to <em>eval()</em> them. Fortunately, people quickly recognised how flawed was this whole idea, so nowadays any knowledgeable developer in sane mind will always use proper safe JSON parser instead.</p>
    singulars
    1. This table or related slice is empty.
    1. POJavaScript framekiller and XSS vulnerability
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USVan Jone
    1. USVan Jone
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POJavaScript framekiller and XSS vulnerability
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTBountyClose
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    1. COThanks a lot for a detailed answer! Now that I have confirmation of framekiller code safety, the only question which remains is what can I do to prevent that scan alert...
      singulars
      1. PO
      1. USaliona
    2. COI reformatted my answer to show correct code as SO ate `<script>` tags. Do you have any concrete code receiving the alert or are you just looking for some framekiller not producing it? What code have you tried so far? One more thought about adapting you code to please AlertLogic is you potentially may introduce real XSS upon making it more complex in order to avoid the warning. So, do weigh your real needs between *showing* you're free from XSS and *being* free from XSS.
      singulars
      1. PO
      1. USVan Jone
    3. COYes, I have concrete code and it is as simple as `if (parent.frames.length > 0) top.location.replace(document.location);` And I do understand that I may introduce a real XSS by trying to make it more complex. And at the same time there is no assurance that more complex code won't cause scan alert
      singulars
      1. PO
      1. USaliona
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload