chetkhatri

%253Ch1%253Eelphant%253C%252Fh1%253E

chetkhatri

object DedupWriter extends Serializable {
  def upsertIntoDeduped(microBatchOutput: DataFrame, batchId: Long): Unit = {
    DeltaTable.forPath("/mnt/somebucket/ip_index_deduped_updates.delta").as("out")
      .merge(
        microBatchOutput.as("in"),
        // all columns match
      )
      .whenNotMatched.insertAll.execute
  }
}

chetkhatri

  import com.example.core.common.ConfigLoader
import com.example.core.common.DeltaWriter._
import scala.concurrent.ExecutionContext.Implicits.global
import scala.concurrent.{Await, Future}
import scala.util.{Failure, Success}
import scala.concurrent.duration.Duration

object Demo extends App {

  if (args.length < 2) {

chetkhatri

import com.example.core.common.ConfigLoader
import com.example.core.common.DeltaWriter._

object Demo extends App {

  if (args.length < 2) {
    logger.error("No Environment type or Network ID are provided as a argument while running spark job")
    System.exit(1)
  }

chetkhatri

import scala.util.{Try, Success, Failure}
val df = Try(spark.read.
     format("com.databricks.spark.xml").
           option("rootTag", "hierarchy").
           option("rowTag", "sms_request").
           load("/tmp/broadcast.xml")) match {
               case Success(df) => df
               case Failure(exception) => throw new Exception("foo")
          }

chetkhatri

XSS alone doesn't do much damage, but it can easily be combined with other techniques to form powerful attack vectors. A few possibilities are:

session hijacking - Often, session cookies can be read from Javascript. Through XSS, a script can be mounted that reads a user's session ID and passes it back to the attacker (a simple yet effective method is to add an img element to the DOM, where the URL of the image carries the session ID); the attacker can then hijack an authenticated session by putting the session ID into their own session cookie.

scraping sensitive information - If a page with an XSS vulnerability contains sensitive information, and send it to the attacker (just like the session cookie).

posting data on someone else's behalf - Through XSS, a form submit can be intercepted and modified, or even triggered, posting data without the user's consent. For example, if you can compromise a web mail client, you could hijack the 'send' button to add yourself to the list of recipients.

malicious redirec

chetkhatri

http://10.234.81.190:8000/api/experimental/dags/phoenix_nextgen_main_dag/dag_runs
{"conf": "{\"network_id\":\"228\" , \"env_name\":\"IADTYPSQL03\", \"size_is\":\"medium\", \"is_full_load\":\"Y\"}", "run_id": "vpn_down_time"}

chetkhatri

https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/XXE%20Injection/README.md

chetkhatri

https://mega.nz/folder/OI9jRKaB#wdT6B-e5MhDv4DBqnEaU4A
https://github.com/payloadbox/xss-payload-list
https://github.com/payloadbox/xss-payload-list/blob/master/Intruder/xss-payload-list.txt
https://github.com/0xsobky/HackVault/wiki/Unleashing-an-Ultimate-XSS-Polyglot
https://github.com/jhaddix/tbhm/blob/master/05_XSS.md
https://www.slideshare.net/MathiasKarlsson2/polyglot-payloads-in-practice-by-avlidienbrunn-at-hackpra
https://github.com/danielmiessler/SecLists/tree/master/Fuzzing/XSS
https://bounty.github.com/researchers/avlidienbrunn.html

chetkhatri

I have a table in MySQL, where one Java program is pushing data at some random time. On another side, I have front end UI which pulls the data from the same table. During the time of writing, UI application is query get stuck with table lock issue.

To overcome this, what I tried is: 

1. Write to table with suffix _java after creation of table tablename_java with that Java program.

2. Once program is completed, rename the original table to _backup

3. Rename tablename_java to table name

4. Drop tablename_backup in next run of step: 1

Table lock issue still exists. Which is obvious.